* [PATCH] OMAP: SPI: Fix the trying to free nonexistent resource error
From: Shubhrajyoti D @ 2011-10-24 10:24 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Shubhrajyoti D
Currently there is a request_mem_region(r->start, ..
followed by r->start += pdata->regs_offset;
And then in remove
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(r->start, resource_size(r));
Here the offset addition is not taken care. Fix the code for the
same.
Signed-off-by: Shubhrajyoti D <shubhrajyoti-l0cyMroinI0@public.gmane.org>
---
drivers/spi/spi-omap2-mcspi.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 06dc9a9..471b0f3 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1123,15 +1123,15 @@ static int __init omap2_mcspi_probe(struct platform_device *pdev)
status = -ENODEV;
goto err1;
}
+ r->start += pdata->regs_offset;
+ r->end += pdata->regs_offset;
+ mcspi->phys = r->start;
if (!request_mem_region(r->start, resource_size(r),
dev_name(&pdev->dev))) {
status = -EBUSY;
goto err1;
}
- r->start += pdata->regs_offset;
- r->end += pdata->regs_offset;
- mcspi->phys = r->start;
mcspi->base = ioremap(r->start, resource_size(r));
if (!mcspi->base) {
dev_dbg(&pdev->dev, "can't ioremap MCSPI\n");
--
1.7.1
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
^ permalink raw reply related
* [U-Boot] CONTACT WESTERN UNION MONEY TRANSFER
From: Maik Miko @ 2011-10-24 10:23 UTC (permalink / raw)
To: u-boot
Attention: Beneficiary.
I am Mr. Maik Miko from Ministry Of Finance Burkina Faso (Head office). This is to bring to you notice that after the conference meeting we had, The Government of this country realized that you are among those that involved in scam victim we have in our list to Compensate by the government of this country as instructions from United Nation(UN).The Governor of this state, Ouagadougou the capital city of Burkina Faso has instructed this office to forward your file to WESTERN UNION MONEY TRANSFER DEPARTMENT to pay you the sum of US$800,000.00 through WESTERN UNION .
His Excellence the GOVERNOR has instructed the WESTERN payment department Dr.Peter Lucas to send the sum of $800,000.00 through his custody for easy receiver of your funds. You are to contact them now to ensure that your fund will be transferring to you once you send them the needed information to avoid wrong transaction.According to the demands of WESTERN UNION MONEY TRANSFER you are to receive your fund at the instalment rate of $5,000.00 daily until the $800,000.00 is completely transferred to you accordingly. You are to contact them now with the bellow information to avoid wrong transaction.
Reconfirm your address
(1)Your Full name: ................
(2)Your Phone number: ...................
(3)Your Contact address: ..................
(4)Your Age: ....................................
Listen very carefully, tell Dr.Peter Lucas that you advise to contact him by Mr. Maik Miko from Ministry Of Finance here in Ouagadougou Burkina Faso;Bellow is their Contact Information.
Contact with this information below:
CONTACT PERSON: DR. PETER LUCAS
Phone number: +226 79 56 75 79
EMAIL: address :( wunionmoneytransfer at wippies.com )
Address: 12 Avenue Akpakpa streets, Ouagadougou, Burkina Faso
Please, do not forget to update me as soon as you receive your first payment.
Best regards.
Mr. Maik Miko.
F.A in Ministry of Finance
Burkina Faso.
^ permalink raw reply
* Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces
From: Rafael J. Wysocki @ 2011-10-24 10:23 UTC (permalink / raw)
To: NeilBrown; +Cc: Linux PM list, mark gross, LKML, John Stultz, Alan Stern
In-Reply-To: <20111024104444.09337fe6@notabene.brown>
On Monday, October 24, 2011, NeilBrown wrote:
> On Sun, 23 Oct 2011 15:16:36 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > On Sunday, October 23, 2011, NeilBrown wrote:
> > > On Sun, 23 Oct 2011 00:07:33 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > >
> > > > On Tuesday, October 18, 2011, NeilBrown wrote:
>
> > > > > >
> > > > > > > With that problem solved, experimenting is much easier in user-space than in
> > > > > > > the kernel.
> > > > > >
> > > > > > Somehow, I'm not exactly sure if we should throw all kernel-based solutions away
> > > > > > just yet.
> > > > >
> > > > > My rule-of-thumb is that we should reserve kernel space for when
> > > > > a/ it cannot be done in user space
> > > > > b/ it cannot be done efficient in user space
> > > > > c/ it cannot be done securely in user space
> > > > >
> > > > > I don't think any of those have been demonstrated yet. If/when they are it
> > > > > would be good to get those kernel-based solutions out of the draw (so yes:
> > > > > keep them out of the rubbish bin).
> > > >
> > > > I have one more rule. If my would-be user space solution has the following
> > > > properties:
> > > >
> > > > * It is supposed to be used by all of the existing variants of user space
> > > > (i.e. all existing variants of user space are expected to use the very same
> > > > thing).
> > > >
> > > > * It requires all of those user space variants to be modified to work with it
> > > > correctly.
> > > >
> > > > * It includes a daemon process having to be started on boot and run permanently.
> > > >
> > > > then it likely is better to handle the problem in the kernel.
> > >
> > > By that set or rules, upowerd, dbus, pulse audio, bluez, and probably systemd
> > > all need to go in the kernel. My guess is that you might not find wide
> > > acceptance for these rules.
> >
> > Well, that's not what I thought. Perhaps I didn't express that precisely
> > enough. Take systemd, for example. You still can design and use a Linux-based
> > system without systemd, so there's no requirement that _all_ variants of user
> > space use the given approach. The choice of whether or not to use systemd
> > is not a choice between a working and non-working system.
> >
> > However, this is not the case with the system daemon, becuase it's supposed
> > to handle problems that aren't possible to address without it. So either you
> > use it, or you end up with a (slightly) broken system.
>
> I think you are seeing a distinction that isn't there.
>
> Every system needs a process to run as 'init' - as PID == 1.
> It might be systemd, it might be sysv-init, it might be /bin/sh, but there
> are tasks that process much perform and there must be exactly one process
> performing those tasks and the test of the systems need to be able to work
> with that task (or ignore if it it is wholely independent).
>
> Similarly every system need one process to manage suspend. It can be my
> daemon or your daemon or Alan's daemon but it cannot be 2 or more of them
> running at the same time as that doesn't make any more sense than having
> systemd and init running at the same time.
I agree that it doesn't makes sense. I don't agree that it implies people
won't try to do that.
> > > > > So I'd respond with "I'm not at all sure that we should throw away an
> > > > > all-userspace solution just yet". Particularly because many of us seem to
> > > > > still be working to understand what all the issues really are.
> > > >
> > > > OK, so perhaps we should try to implement two concurrent solutions, one
> > > > kernel-based and one purely in user space and decide which one is better
> > > > afterwards?
> > >
> > > Absolutely.
> > >
> > > My primary reason for entering this discussion is eloquently presented in
> > > http://xkcd.com/386/
> > >
> > > Someone said "We need to change the kernel to get race-free suspend" and this
> > > simply is not true. I wanted to present a way to use the existing
> > > functionality to provide race-free suspend - and now even have code to do it.
> > >
> > > If someone else wants to write a different implementation, either in
> > > userspace or kernel that is fine.
> > >
> > > They can then present it as "I know this can be implemented in userspace, but
> > > I don't like that solution for reasons X, Y, Z and so here is my better
> > > kernel-space implementation" then that is cool. We can examine X, Y, Z and
> > > the code and see if the argument holds up. Maybe it will, maybe not.
> > >
> > > So far the only arguments I've seen for putting the code in the kernel are:
> > >
> > > 1/ it cannot be done in userspace - demonstrably wrong
> >
> > I'm not sure if that's correct. If you meant "it can be done in user space
> > without _any_ kernel modifications", I probably wouldn't agree.
>
> I have code to do it correctly today with no kernel modifications. It is
> called "lsusd". Proof by example. Or can you show that lsusd doesn't work
> correctly?
So why do you consider making changes to the kernel (described in the other
part of the thread)? Are they completely cosmetic or are they needed for
functionality?
> > > 2/ it is more efficient in the kernel - not demonstrated or even
> > > convincingly argued
> >
> > I don't agree with that, but let's see.
>
> If you don't agree, then you presumably have a demonstration or a convincing
> argument. Can you share it?
I think I'll post a patch, but it'll take some time for me to develop it.
> > > 3/ doing it in user-space is too confusing - we would need a clear
> > > demonstration that a kernel interface is less confusing - and still
> > > correct. Also the best way to remove confusion is with clear
> > > documentation and sample code, not by making up new interfaces.
> >
> > The user space solution makes up new interfaces too, although they are
> > confined to user space.
> >
> > To me, it all boils down to two factors: (1) the complexity and efficiency
> > of the code needed to implement the feature and (2) the complexity of the
> > resulting framework (be it in the kernel or in user space).
> >
> > > 4/ doing it in the kernel makes it more accessible to multiple desktops.
> > > The success of freedesktop.org seems to contradict that.
> >
> > I don't agree here too. Is Android a member of freedesktop.org?
> >
>
> This is completely irrelevant.
>
> The "multiple desktops" issue that you brought up is (as I understand it)
> multiple desktops running on the same computer, whether concurrently or
> sequentially.
> Android simply does not face that issue - it is the only "desktop" and is in
> complete control of the machine it runs on.
> So it doesn't need to solve the issue, so it doesn't need to be a member of
> freedesktop.org.
I didn't understand what you meant by "multiple desktops", sorry about that.
> > > So if you can do it a "better" way, please do. But also please make sure
> > > you can quantify "better". I claim that user-space solutions are "better"
> > > because they are more flexible and easier to experiment with. The "no
> > > regressions" rule actively discourages experimentation in the kernel so
> > > people should only do it if there is a clear benefit.
> >
> > You seem to suppose that every kernel modification necessarily has a potential
> > to lead to some regressions. I'm not exactly use if that's correct
> > (e.g. adding a new driver usually doesn't affect people who don't need it).
>
> I think that experimenting in the kernel (or at least in the upstream kernel)
> is likely to result in creating functionality that ultimately will
> not get used - the whole point of experimenting is that you probably get it
> wrong the first time.
> If this happens we either:
> - remove the unwanted functionality, which could be considered a regression
> and so must be done very carefully
Unless nobody uses it, that is. :-)
> - leave the unwanted functionality there thus creating clutter and a
> maintenance burden.
I don't see this as a big problem. I can handle that at least. :-)
> i.e. the point of the "no-regressions" reference is that it tends to make it
> harder to remove mistakes. Not impossible of course, but it requires a lot
> more care and time.
>
> So I am against adding code to the kernel until the problem is really well
> understood. From the sorts of discussion that has been going on both in
> this thread and elsewhere I'm not convinced the problem really is well
> understood at all.
> I think we are very much at the stage where people should be experimenting
> with solutions, sharing the results, and learning.
>
> So please feel free to publish sample code - whether for the kernel or for
> user-space. But it will only be credible if it is a fairly complete
> proposal - e.g. with sample code demonstrating how the kernel features are
> used.
>
> (my lsusd really needs a 'plugin' for pm_utils to get it to communicate with
> lsusd rather than writing to /sys/power/state ... I should probably add
> that. Then it would be complete and usable on current desktops).
I'm actually glad that lsusd has been developed, that's something I've been
advocating for quite a while. Still, I'm not sure how useful it turns out
to be for distros etc.
> > > User-space solutions are much easier to introduce and then deprecate.
> >
> > That's demonstrably incorrect and the counter example is the hibernation user
> > space interface. The sheer amount of work needed to implement user
> > space-driven hibernation and maintain that code shows that it's not exactly
> > easy and it would be more difficult to deprecate than many existing kernel
> > interfaces at this point.
> >
> > So, even if you have implemented something in user space, the "no regressions"
> > rule and deprecation difficulties will apply to it as well as to the kernel as
> > soon as you make a sufficient number of people use it.
>
> Can we agree then that we shouldn't impose any part of a possible solution on
> anyone until it has been sensibly tested and reviewed in a variety of
> different use cases and found to be reliable and usable?
Yes, of course. That's why my patches in this area have been added the RFC
label in the first place.
> I think that addresses my main concern with kernel-space additions - I fear
> that parts of them will end up unnecessary and unused but we will be stuck
> with them.
OK
Thanks,
Rafael
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Jan Kiszka @ 2011-10-24 10:19 UTC (permalink / raw)
To: Avi Kivity; +Cc: Marcelo Tosatti, kvm, Michael S. Tsirkin
In-Reply-To: <4EA533B8.4040407@redhat.com>
On 2011-10-24 11:45, Avi Kivity wrote:
> On 10/21/2011 11:19 AM, Jan Kiszka wrote:
>> Currently, MSI messages can only be injected to in-kernel irqchips by
>> defining a corresponding IRQ route for each message. This is not only
>> unhandy if the MSI messages are generated "on the fly" by user space,
>> IRQ routes are a limited resource that user space as to manage
>> carefully.
>
> By itself, this does not provide enough value to offset the cost of a
> new ABI, especially as userspace will need to continue supporting the
> old method for a very long while.
Yes, but less sophistically as it would now.
>
>> By providing a direct injection with, we can both avoid using up limited
>> resources and simplify the necessary steps for user land. The API
>> already provides a channel (flags) to revoke an injected but not yet
>> delivered message which will become important for in-kernel MSI-X vector
>> masking support.
>>
>
> With the new feature it may be worthwhile, but I'd like to see the whole
> thing, with numbers attached.
It's not a performance issue, it's a resource limitation issue: With the
new API we can stop worrying about user space device models consuming
limited IRQ routes of the KVM subsystem.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 10:17 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linus Walleij, Sebastian Rasmussen, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Lee Jones
In-Reply-To: <20111024095638.GJ9893@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Mon, Oct 24, 2011 at 11:54:00AM +0200, Linus Walleij wrote:
>> On Mon, Oct 24, 2011 at 11:36 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sun, Oct 23, 2011 at 02:31:39AM +0200, Sebastian Rasmussen wrote:
>>>> I guess the patch would appeal more to Russell if mmci_runtime_suspend()
>>>> only cleared MCIMask0/SDI_MASK0 and MCIClock/SDI_CLKCR and left
>>>> MCIPower/SDI_PWR unchanged. It may be the case that the signal direction
>>>> bits need to be cleared for the ST-Ericsson PL180, but I haven't yet verified
>>>> this on my Snowball dev board yet.
>>> There's also the issue that the specs call for the clock to run after
>>> a command has completed for a certain number of cycles, and that the
>>> clock must continue to run until the card reports not-busy after a
>>> programming or erase cycle has completed - that can be long after the
>>> previous command has 'completed'.
>> It's 8 cycles on MCLK required.
>
> _Plus_ keeping the clock running while the card is signalling busy.
>
> If you don't clock the card while its signalling busy, it will never
> go non-busy (the data line becomes frozen.)
>
Good point!
Is the aggressive clk gating feature in the mmc framework taking this
into account as well?
Potentially the framework could do a get_sync/put (in claim/release
host) to prevent hosts from being runtime disabled. Similar how the
enable/disable mechanism is working.
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024095638.GJ9893@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Mon, Oct 24, 2011 at 11:54:00AM +0200, Linus Walleij wrote:
>> On Mon, Oct 24, 2011 at 11:36 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sun, Oct 23, 2011 at 02:31:39AM +0200, Sebastian Rasmussen wrote:
>>>> I guess the patch would appeal more to Russell if mmci_runtime_suspend()
>>>> only cleared MCIMask0/SDI_MASK0 and MCIClock/SDI_CLKCR and left
>>>> MCIPower/SDI_PWR unchanged. It may be the case that the signal direction
>>>> bits need to be cleared for the ST-Ericsson PL180, but I haven't yet verified
>>>> this on my Snowball dev board yet.
>>> There's also the issue that the specs call for the clock to run after
>>> a command has completed for a certain number of cycles, and that the
>>> clock must continue to run until the card reports not-busy after a
>>> programming or erase cycle has completed - that can be long after the
>>> previous command has 'completed'.
>> It's 8 cycles on MCLK required.
>
> _Plus_ keeping the clock running while the card is signalling busy.
>
> If you don't clock the card while its signalling busy, it will never
> go non-busy (the data line becomes frozen.)
>
Good point!
Is the aggressive clk gating feature in the mmc framework taking this
into account as well?
Potentially the framework could do a get_sync/put (in claim/release
host) to prevent hosts from being runtime disabled. Similar how the
enable/disable mechanism is working.
^ permalink raw reply
* [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
From: Marek Vasut @ 2011-10-24 10:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <m2k47uog3p.fsf@ohwell.denx.de>
On Monday, October 24, 2011 12:10:02 PM Detlev Zundel wrote:
> Hi Marek,
>
> [...]
>
> > So because noone actually bothered to compile u-boot with DEBUG enabled,
> > we (me ?) now have literally piles of places to fix. Hm :-(
>
> So it seems. This is a very good reminder of the fact that with ifdef
> we actually hide source code from the compiler under certain
> circumstances. The number of these "certain circumstances" produces the
> number of _differing input_ to our compiler. Given the trivial fact
> that a simple ifdef results in two different inputs one needs only to
> visualize the graph of 2^x to get an idea of how many sources we are
> actually using.
>
> Unrelated to your current efforts (that are greatly appreciated) We
> should really try not to use #ifdef at all. Using constants together
> with the dead code eliminatino of the compiler can usually reach the
> same goal but with syntax checks on every compile.
>
> Sorry, but I couldn't resist lobbying for this. Perhaps it helps when
> it gets repeated approximately every year ;)
>
> Cheers
> Detlev
Hey Detlev,
I certainly see your point. Btw. do you feel like help reviewing the PPC portion
of the patches? That'd be greatly appreciated as I'm not a PPC expert. I wanted
to avoid resubmission, so I only pushed the new set to git://git.denx.de/u-boot-
marex.git / debug branch. There is over 50 patches now.
Cheers
^ permalink raw reply
* Re: [PATCH RFC V2 4/5] kvm guest : Added configuration support to enable debug information for KVM Guests
From: Avi Kivity @ 2011-10-24 10:15 UTC (permalink / raw)
To: Raghavendra K T
Cc: Greg Kroah-Hartman, KVM, Sedat Dilek, Ingo Molnar, Virtualization,
Jeremy Fitzhardinge, x86, H. Peter Anvin, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Gleb Natapov, Yinghai Lu,
Marcelo Tosatti, Xen, Rik van Riel, Konrad Rzeszutek Wilk, LKML,
Suzuki Poulose, Srivatsa Vaddagiri, Peter Zijlstra
In-Reply-To: <20111023190700.16364.7548.sendpatchset@oc5400248562.ibm.com>
On 10/23/2011 09:07 PM, Raghavendra K T wrote:
> Added configuration support to enable debug information
> for KVM Guests in debugfs
>
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 1f03f82..ed34269 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -562,6 +562,15 @@ config KVM_GUEST
> This option enables various optimizations for running under the KVM
> hypervisor.
>
> +config KVM_DEBUG_FS
> + bool "Enable debug information for KVM Guests in debugfs"
> + depends on KVM_GUEST
> + default n
> + ---help---
> + This option enables collection of various statistics for KVM guest.
> + Statistics are displayed in debugfs filesystem. Enabling this option
> + may incur significant overhead.
> +
> source "arch/x86/lguest/Kconfig"
>
>
This might be better implemented through tracepoints, which an be
enabled dynamically.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock
From: Avi Kivity @ 2011-10-24 10:14 UTC (permalink / raw)
To: Raghavendra K T
Cc: Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov, Virtualization,
Jeremy Fitzhardinge, x86, KVM, Dave Jiang, Thomas Gleixner,
Stefano Stabellini, Xen, Sedat Dilek, Yinghai Lu, Marcelo Tosatti,
Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk, LKML,
Suzuki Poulose, Srivatsa Vaddagiri, Peter Zijlstra
In-Reply-To: <20111023190558.16364.2136.sendpatchset@oc5400248562.ibm.com>
On 10/23/2011 09:05 PM, Raghavendra K T wrote:
> Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
>
> KVM_HC_WAIT_FOR_KICK blocks the calling vcpu until another vcpu kicks it or it
> is woken up because of an event like interrupt.
>
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu.
>
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_WAIT_FOR_KICK/KVM_CAP_WAIT_FOR_KICK.
>
> Qemu needs a corresponding patch to pass up the presence of this feature to
> guest via cpuid. Patch to qemu will be sent separately.
>
> There is no Xen/KVM hypercall interface to await kick from.
>
>
> +/*
> + * kvm_pv_wait_for_kick_op : Block until kicked by either a KVM_HC_KICK_CPU
> + * hypercall or a event like interrupt.
> + *
> + * @vcpu : vcpu which is blocking.
> + */
> +static void kvm_pv_wait_for_kick_op(struct kvm_vcpu *vcpu)
> +{
> + DEFINE_WAIT(wait);
> +
> + /*
> + * Blocking on vcpu->wq allows us to wake up sooner if required to
> + * service pending events (like interrupts).
> + *
> + * Also set state to TASK_INTERRUPTIBLE before checking vcpu->kicked to
> + * avoid racing with kvm_pv_kick_cpu_op().
> + */
> + prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
> +
> + /*
> + * Somebody has already tried kicking us. Acknowledge that
> + * and terminate the wait.
> + */
> + if (vcpu->kicked) {
> + vcpu->kicked = 0;
> + goto end_wait;
> + }
> +
> + /* Let's wait for either KVM_HC_KICK_CPU or someother event
> + * to wake us up.
> + */
> +
> + srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
> + schedule();
> + vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
> +
> +end_wait:
> + finish_wait(&vcpu->wq, &wait);
> +}
This hypercall can be replaced by a HLT instruction, no?
I'm pretty sure this misses a lot of stuff from kvm_vcpu_block().
> +
> +/*
> + * kvm_pv_kick_cpu_op: Kick a vcpu.
> + *
> + * @cpu - vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> +{
> + struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
> +
Is the vcpu number meaningful? We should reuse an existing identifier
like the APIC ID.
> + if (vcpu) {
> + vcpu->kicked = 1;
Need to use smp memory barriers here.
> + wake_up_interruptible(&vcpu->wq);
> + }
> +}
> +
> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> {
> unsigned long nr, a0, a1, a2, a3, ret;
>
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* [Xenomai-core] some problems with interrupts
From: Roberto Bielli @ 2011-10-24 10:14 UTC (permalink / raw)
To: xenomai
Hi,
i installed the patch 'adeos-ipipe-2.6.31-arm-1.16-02.patch' on a kernel
2.6.31 for imx257 processor.
I have a xenomai complex application that read touchscreen events with
tslib when pressed.
In the kernel log i try these lines: ( the read job is made in a
not-realtime thread )
------------[ cut here ]------------
WARNING: at drivers/input/touchscreen/mxc_tsc.c:599
mxc_tsc_interrupt+0x19c/0x30c [mxc_tsc]()
Modules linked in: can_raw can flexcan sdhci_mxc ehci_hcd mmc_core
usbcore mxc_tsc nls_base
Backtrace:
[<c0028150>] (dump_backtrace+0x0/0x114) from [<c02c9a48>]
(dump_stack+0x18/0x1c)
r7:bf0054bc r6:00000257 r5:bf0046d8 r4:00000000
[<c02c9a30>] (dump_stack+0x0/0x1c) from [<c0043390>]
(warn_slowpath_common+0x50/0x68)
[<c0043340>] (warn_slowpath_common+0x0/0x68) from [<c00433c0>]
(warn_slowpath_null+0x18/0x1c)
r7:0000002e r6:00000001 r5:00008013 r4:d1959400
[<c00433a8>] (warn_slowpath_null+0x0/0x1c) from [<bf0046d8>]
(mxc_tsc_interrupt+0x19c/0x30c [mxc_tsc])
[<bf00453c>] (mxc_tsc_interrupt+0x0/0x30c [mxc_tsc]) from [<c007242c>]
(handle_IRQ_event+0x3c/0x124)
r7:0000002e r6:00000000 r5:00000000 r4:d1c69840
[<c00723f0>] (handle_IRQ_event+0x0/0x124) from [<c007466c>]
(handle_level_irq+0x98/0x12c)
r7:0000002e r6:d1c69840 r5:0000002e r4:c0399b70
[<c00745d4>] (handle_level_irq+0x0/0x12c) from [<c0023070>]
(_text+0x70/0x8c)
r7:0000002e r6:c03fc240 r5:00000000 r4:0000002e
[<c0023000>] (_text+0x0/0x8c) from [<c0076ee8>]
(__ipipe_sync_stage+0x180/0x268)
Exception stack(0xc038ff40 to 0xc038ff88)
ff40: 00000020 00000004 c03fc264 fffffffd 00000000 ffffffff 00000001
c038e000
ff60: c039d540 c0392418 c03b7444 8001f200 41069264 8001f1cc c038ff94
c038ff88
ff80: c0077770 c0076d78
r5:c039d508 r4:c03fc260
[<c0076d68>] (__ipipe_sync_stage+0x0/0x268) from [<c0077770>]
(__ipipe_unstall_root+0x3c/0x50)
[<c0077734>] (__ipipe_unstall_root+0x0/0x50) from [<c00257a8>]
(cpu_idle+0x64/0xcc)
[<c0025744>] (cpu_idle+0x0/0xcc) from [<c02c6eb0>] (rest_init+0x78/0x8c)
r7:c0392410 r6:c0020e14 r5:c0020e18 r4:c038e000
[<c02c6e38>] (rest_init+0x0/0x8c) from [<c00089a4>]
(start_kernel+0x284/0x2e0)
r5:c0020e18 r4:c0410190
[<c0008720>] (start_kernel+0x0/0x2e0) from [<80008034>] (0x80008034)
r5:c03b74cc r4:00053175
---[ end trace c83bf7139f281ac6 ]---
mx25-tsc mx25-tsc: mxc_tsc_read_ts: Failed to get data
Do you know the meaning in xenomai of this error (so i can modify
something to resolve the problem )?
Thanks a lot
--
+------------------------------------------------------------------------------------------------+
Roberto Bielli
Sviluppo Software
Axel S.r.l.
Via Del Cannino, 3
21020 Crosio Della Valle
Varese - Italy
Telefono: +39 0332 949600
Fax: +39 0332 969315
E-mail: roberto.bielli@domain.hid
Web Site: www.axelsw.it
+------------------------------------------------------------------------------------------------+
Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid
This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.
+------------------------------------------------------------------------------------------------+
^ permalink raw reply
* Re: [PATCHv5 16/19] power_supply: Convert all users to new usb_phy
From: Heikki Krogerus @ 2011-10-24 10:14 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linux-kernel
In-Reply-To: <20111010190812.GA12821@oksana.dev.rtsoft.ru>
Hi,
On Mon, Oct 10, 2011 at 11:08:12PM +0400, Anton Vorontsov wrote:
> On Mon, Oct 03, 2011 at 04:10:55PM +0300, Heikki Krogerus wrote:
> [...]
> > > +static inline int
> > > +isp1704_read(struct isp1704_charger *isp, u32 reg)
>
> Cosmetic nitpick: I don't see any reason to break this into two lines.
>
> > > +{
> > > + return usb_phy_io_read(isp->xceiv, reg);
> > > +}
> > > +
> > > +static inline int
> > > +isp1704_write(struct isp1704_charger *isp, u32 val, u32 reg)
>
> Same here.
>
> I assume you want this patch to go via some other tree, so feel
> free to add
>
> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
>
> Thanks!
Thanks Anton. I'll change them.
--
heikki
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Russell King - ARM Linux @ 2011-10-24 10:14 UTC (permalink / raw)
To: Ulf Hansson
Cc: Sebastian Rasmussen, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Lee Jones
In-Reply-To: <4EA538A3.9070501@stericsson.com>
On Mon, Oct 24, 2011 at 12:06:27PM +0200, Ulf Hansson wrote:
> Russell King - ARM Linux wrote:
>> On Mon, Oct 24, 2011 at 11:36:01AM +0200, Ulf Hansson wrote:
>>> Russell King - ARM Linux wrote:
>>>> I repeat: if you cut power to the card, you have to re-initialize it.
>>>> Re-initialization takes quite a bit of time to re-detect and setup
>>>> the card. You'd also need to re-configure things like the transfer
>>>> mode and so forth.
>>> Right now host->vcc (vmmc) regulator is controlling the power to
>>> card. Not the MCIPWR register!
>>
>> Maybe for you, but that's not the case on all platforms.
>>
>> You *really* need to get out of the idea that just because your
>> implementation works one way that everything works that way. You're
>> working on a cross-SoC cross-platform driver, and you need to take
>> account of how other platforms work.
>
> Sorry for being a pain in the ass. :-) I am thinking of the above, even
> if it not seems like that.
>
>>
>> In that case, there *are* platforms which the MCIPWR register does
>> indeed control power to the card - and setting this to zero _will_
>> power down the card.
>>
>>> I would be very surprised if any hardware has this kind of setup,
>>> that the PL180 itself controls a regulator.
>>
>> ARM dev boards all use the MCIPWR bits to control an external power
>> switch - there's no adjustment of the voltage except via soldered
>> links on the board.
>
> That explains it!
>
> My believe was that since the bits for controlling the voltage levels
> etc was not used (which is replaced with directions bits for
> ST-version), this functionality was not used either.
>
> Could you maybe elaborate a bit of how the power is controlled in the
> ARM dev boards? Would it be possible to control such a switch in "GPIO"
> manner instead? For example via the vdd_handler or similar?
>
> I will also think if and see if is feasible to re-design and see if this
> hole feature can be controlled by the variant struct instead. My feeling
> is although it can be kind of messy. But let's see...
The MCIPWR register contains two bits to control _the_ _power_ _state_.
See Table A-4: the MCIPWR signal. See section 2.2.2. See section 3.3.1.
The MCIPWR signal controls the external power switch. This is the only
signal for it. This is the only connection for it. There is no other
control form for this power switch.
^ permalink raw reply
* [U-Boot] [PATCH 2/2 V2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code
From: Marek Vasut @ 2011-10-24 10:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1317860006-18212-2-git-send-email-marek.vasut@gmail.com>
This allows the SPL to avoid compiling in the CPU support code.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Scott Wood <scottwood@freescale.com>
---
arch/arm/cpu/arm926ejs/Makefile | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
V2: Don't frob with cpu.o as it's going to be removed anyway.
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile
index 930e0d1..a56ff08 100644
--- a/arch/arm/cpu/arm926ejs/Makefile
+++ b/arch/arm/cpu/arm926ejs/Makefile
@@ -28,6 +28,12 @@ LIB = $(obj)lib$(CPU).o
START = start.o
COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD
+ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE
+START :=
+endif
+endif
+
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
START := $(addprefix $(obj),$(START))
--
1.7.6.3
^ permalink raw reply related
* [PATCH] mmc: mmci: Improve runtime PM support
From: Russell King - ARM Linux @ 2011-10-24 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA538A3.9070501@stericsson.com>
On Mon, Oct 24, 2011 at 12:06:27PM +0200, Ulf Hansson wrote:
> Russell King - ARM Linux wrote:
>> On Mon, Oct 24, 2011 at 11:36:01AM +0200, Ulf Hansson wrote:
>>> Russell King - ARM Linux wrote:
>>>> I repeat: if you cut power to the card, you have to re-initialize it.
>>>> Re-initialization takes quite a bit of time to re-detect and setup
>>>> the card. You'd also need to re-configure things like the transfer
>>>> mode and so forth.
>>> Right now host->vcc (vmmc) regulator is controlling the power to
>>> card. Not the MCIPWR register!
>>
>> Maybe for you, but that's not the case on all platforms.
>>
>> You *really* need to get out of the idea that just because your
>> implementation works one way that everything works that way. You're
>> working on a cross-SoC cross-platform driver, and you need to take
>> account of how other platforms work.
>
> Sorry for being a pain in the ass. :-) I am thinking of the above, even
> if it not seems like that.
>
>>
>> In that case, there *are* platforms which the MCIPWR register does
>> indeed control power to the card - and setting this to zero _will_
>> power down the card.
>>
>>> I would be very surprised if any hardware has this kind of setup,
>>> that the PL180 itself controls a regulator.
>>
>> ARM dev boards all use the MCIPWR bits to control an external power
>> switch - there's no adjustment of the voltage except via soldered
>> links on the board.
>
> That explains it!
>
> My believe was that since the bits for controlling the voltage levels
> etc was not used (which is replaced with directions bits for
> ST-version), this functionality was not used either.
>
> Could you maybe elaborate a bit of how the power is controlled in the
> ARM dev boards? Would it be possible to control such a switch in "GPIO"
> manner instead? For example via the vdd_handler or similar?
>
> I will also think if and see if is feasible to re-design and see if this
> hole feature can be controlled by the variant struct instead. My feeling
> is although it can be kind of messy. But let's see...
The MCIPWR register contains two bits to control _the_ _power_ _state_.
See Table A-4: the MCIPWR signal. See section 2.2.2. See section 3.3.1.
The MCIPWR signal controls the external power switch. This is the only
signal for it. This is the only connection for it. There is no other
control form for this power switch.
^ permalink raw reply
* Re: [PATCH bluez] add get_le/get_be helpers
From: Vinicius Gomes @ 2011-10-24 10:13 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1319448004-8513-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Mon, Oct 24, 2011 at 11:20 AM, Emeltchenko Andrei
<Andrei.Emeltchenko.news@gmail.com> wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>
> Helpers to access LE / BE values. In bluetooth there is a mixture
> of LE / BE network byte order.
> ---
Sorry if this comes too late, but here's an idea:
How about changing the name of the functions to something a little
more high level, for example: in attrib/att.h we have
att_{get,put}_u16() that uses the byte order defined in the ATT spec
(little endian).
So my suggestion is to have bt_{get,put}_u*() and sdp_{get,put}_u*
functions (perhaps also no_{get,put}_u* for cases when we use the host
byte order). The bt_ functions will be used for everything that uses
the Bluetooth byte order and the sdp_ ones for SDP, which is the only
case of Big Endian defined by Bluetooth, correct me if I am wrong.
What do you think?
> lib/bluetooth.h | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 64 insertions(+), 0 deletions(-)
>
> diff --git a/lib/bluetooth.h b/lib/bluetooth.h
> index b0680e2..5bd4f03 100644
> --- a/lib/bluetooth.h
> +++ b/lib/bluetooth.h
> @@ -125,6 +125,70 @@ do { \
> __p->__v = (val); \
> } while(0)
>
> +#if __BYTE_ORDER == __LITTLE_ENDIAN
> +static inline uint64_t bt_get_le64(void *ptr)
> +{
> + return bt_get_unaligned((uint64_t *) ptr);
> +}
> +
> +static inline uint64_t bt_get_be64(void *ptr)
> +{
> + return bswap_64(bt_get_unaligned((uint64_t *) ptr));
> +}
> +
> +static inline uint32_t bt_get_le32(void *ptr)
> +{
> + return bt_get_unaligned((uint32_t *) ptr);
> +}
> +
> +static inline uint32_t bt_get_be32(void *ptr)
> +{
> + return bswap_32(bt_get_unaligned((uint32_t *) ptr));
> +}
> +
> +static inline uint16_t bt_get_le16(void *ptr)
> +{
> + return bt_get_unaligned((uint16_t *) ptr);
> +}
> +
> +static inline uint16_t bt_get_be16(void *ptr)
> +{
> + return bswap_16(bt_get_unaligned((uint16_t *) ptr));
> +}
> +#elif __BYTE_ORDER == __BIG_ENDIAN
> +static inline uint64_t bt_get_le64(void *ptr)
> +{
> + return bswap_64(bt_get_unaligned((uint64_t *) ptr));
> +}
> +
> +static inline uint64_t bt_get_be64(void *ptr)
> +{
> + return bt_get_unaligned((uint64_t *) ptr);
> +}
> +
> +static inline uint32_t bt_get_le32(void *ptr)
> +{
> + return bswap_32(bt_get_unaligned((uint32_t *) ptr));
> +}
> +
> +static inline uint32_t bt_get_be32(void *ptr)
> +{
> + return bt_get_unaligned((uint32_t *) ptr);
> +}
> +
> +static inline uint16_t bt_get_le16(void *ptr)
> +{
> + return bswap_16(bt_get_unaligned((uint16_t *) ptr));
> +}
> +
> +static inline uint16_t bt_get_be16(void *ptr)
> +{
> + return bt_get_unaligned((uint16_t *) ptr);
> +}
> +#else
> +#error "Unknown byte order"
> +#endif
> +
> /* BD Address */
> typedef struct {
> uint8_t b[6];
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Cheers,
--
Vinicius
^ permalink raw reply
* Re: Possible diff regression in v1.7.6-473-g27af01d
From: Tay Ray Chuan @ 2011-10-24 10:11 UTC (permalink / raw)
To: Thomas Rast
Cc: Franz Schrober, git@vger.kernel.org, marat@slonopotamus.org,
gitster@pobox.com
In-Reply-To: <201110241138.51448.trast@student.ethz.ch>
On Mon, Oct 24, 2011 at 5:38 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>
> I'm not sure why you call this a regression. For the benefit of
> people who hate saving attachments, you used
>
> $ paste anonymized_orig anonymized_new | xclip
> 0 1
> 0 2
> 0 0
> 0 3
> 4
> 5
> 6
> 7
>
> the old diff was
>
> --- a/anonymized_orig
> +++ b/anonymized_new
> @@ -1,4 +1,8 @@
> -0
> -0
> -0
> -0
> +1
> +2
> +0
> +3
> +4
> +5
> +6
> +7
>
> and the new diff is
>
> --- a/anonymized_orig
> +++ b/anonymized_new
> @@ -1,4 +1,8 @@
> +1
> +2
> 0
> -0
> -0
> -0
> +3
> +4
> +5
> +6
> +7
>
> So the new diff correctly represents the change, and on top of that is
> shorter (by only one line, admittedly). What makes it a regression?
Thanks for inlining it, Thomas.
> Franz Schrober wrote:>> Hi,>>>> I am using git to manage some patches on top of the actual upstream files, but noticed that the result of git-format-patch changed between 4bfe7cb6668c43c1136304bbb17eea1b3ddf0237 and 27af01d552331eacf1ed2671b2b4b6ad4c268106>>>> I've attached two input files (I tried to provide a minimal example... I am not sure if a smaller example is possible but at least both files are smaller than 10 lines) and the results with version 1.7.6.3 and and 1.7.7. The diffs were created using: git diff anonymized_orig anonymized_new>>>> My .gitconfig file is empty.
This has been "fixed" in v1.7.7.1, with 713b85c (Merge branch
'rs/diff-cleanup-records-fix' into maint) - "fixed" in that it gives
back the old behaviour, not that the diff produced is incorrect and
needs fixing.
(I'm running 1.7.7.1.599.g03eec, I get the same diff as diff.1.7.6.3)
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH] mmc: core: Separate the timeout value for cache-ctrl
From: Seungwon Jeon @ 2011-10-24 10:10 UTC (permalink / raw)
To: linux-mmc; +Cc: cjb, linux-samsung-soc, kgene.kim, dh.han
Turning the cache off implies flushing cache which doesn't define
maximum timeout unlike cache-on. This patch will apply the generic
CMD6 timeout only for cache-on. Additionally the kernel message is
added for checking failure case of cache-on.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
---
drivers/mmc/core/core.c | 22 +++++++++++++---------
drivers/mmc/core/mmc.c | 10 ++++++++--
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 5278ffb..65b5643 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2248,6 +2248,7 @@ EXPORT_SYMBOL(mmc_flush_cache);
int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
{
struct mmc_card *card = host->card;
+ unsigned int timeout;
int err = 0;
if (!(host->caps2 & MMC_CAP2_CACHE_CTRL) ||
@@ -2258,16 +2259,19 @@ int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
(card->ext_csd.cache_size > 0)) {
enable = !!enable;
- if (card->ext_csd.cache_ctrl ^ enable)
+ if (card->ext_csd.cache_ctrl ^ enable) {
+ timeout = enable ? card->ext_csd.generic_cmd6_time : 0;
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_CACHE_CTRL, enable, 0);
- if (err)
- pr_err("%s: cache %s error %d\n",
- mmc_hostname(card->host),
- enable ? "on" : "off",
- err);
- else
- card->ext_csd.cache_ctrl = enable;
+ EXT_CSD_CACHE_CTRL, enable, timeout);
+
+ if (err)
+ pr_err("%s: cache %s error %d\n",
+ mmc_hostname(card->host),
+ enable ? "on" : "off",
+ err);
+ else
+ card->ext_csd.cache_ctrl = enable;
+ }
}
return err;
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index fb5bf01..6354eb3 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1064,14 +1064,20 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
if ((host->caps2 & MMC_CAP2_CACHE_CTRL) &&
card->ext_csd.cache_size > 0) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_CACHE_CTRL, 1, 0);
+ EXT_CSD_CACHE_CTRL, 1,
+ card->ext_csd.generic_cmd6_time);
if (err && err != -EBADMSG)
goto free_card;
/*
* Only if no error, cache is turned on successfully.
*/
- card->ext_csd.cache_ctrl = err ? 0 : 1;
+ if (err) {
+ pr_warning("%s: Cache is supported, but enabling failed\n",
+ mmc_hostname(card->host));
+ err = 0;
+ } else
+ card->ext_csd.cache_ctrl = 1;
}
if (!oldcard)
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC][PATCH 3/3] ASoC: wm8940: Do not left shift the div parameter in wm8940_set_dai_clkdiv
From: Mark Brown @ 2011-10-24 10:10 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, Dimitris Papastamos, Liam Girdwood, alsa-devel
In-Reply-To: <1319427312.5773.6.camel@phoenix>
On Mon, Oct 24, 2011 at 11:35:12AM +0800, Axel Lin wrote:
> Just check with other codec drivers, we do left shit div for
> the corresponding bits from the caller in all other drivers.
> I don't find the caller calling wm8940_set_dai_clkdiv now,
> just make the behavior consistent with other drivers.
The semantics for the clkdivs are entirely defined by the individual
drivers - there's no actual standard here and I guess this may break
some out of tree machines that people have. If we're going to a cleanup
here it'd be better to improve the driver to figure out the divider
configurations automatically as far as possible.
^ permalink raw reply
* [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
From: Detlev Zundel @ 2011-10-24 10:10 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110230017.34182.marek.vasut@gmail.com>
Hi Marek,
[...]
> So because noone actually bothered to compile u-boot with DEBUG enabled, we (me
> ?) now have literally piles of places to fix. Hm :-(
So it seems. This is a very good reminder of the fact that with ifdef
we actually hide source code from the compiler under certain
circumstances. The number of these "certain circumstances" produces the
number of _differing input_ to our compiler. Given the trivial fact
that a simple ifdef results in two different inputs one needs only to
visualize the graph of 2^x to get an idea of how many sources we are
actually using.
Unrelated to your current efforts (that are greatly appreciated) We
should really try not to use #ifdef at all. Using constants together
with the dead code eliminatino of the compiler can usually reach the
same goal but with syntax checks on every compile.
Sorry, but I couldn't resist lobbying for this. Perhaps it helps when
it gets repeated approximately every year ;)
Cheers
Detlev
--
F?r jemanden, der in eine Religion geboren wurde, in der das Ringen um eine
einzige Seele ein Stafettenlauf ?ber viele Jahrhunderte sein kann [..], hat
das Tempo des Christentums etwas Schwindelerregendes. Wenn der Hinduismus
friedlich dahinflie?t wie der Ganges, dann ist das Christentum Toronto in
der Rushhour. -- Yann Martel
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply
* Re: [lm-sensors] [PATCH 5/6] IIO:hwmon interface client driver.
From: Jonathan Cameron @ 2011-10-24 10:09 UTC (permalink / raw)
To: Jonathan Cameron
Cc: guenter.roeck, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, linus.ml.walleij@gmail.com,
zdevai@gmail.com, linux@arm.linux.org.uk, arnd@arndb.de,
broonie@opensource.wolfsonmicro.com, gregkh@suse.de,
lm-sensors@lm-sensors.org, khali@linux-fr.org,
thomas.petazzoni@free-electrons.com,
maxime.ripard@free-electrons.com
In-Reply-To: <4EA03E8D.1010303@cam.ac.uk>
On 10/20/11 16:30, Jonathan Cameron wrote:
> On 10/20/11 16:12, Guenter Roeck wrote:
>> On Thu, 2011-10-20 at 05:33 -0400, Jonathan Cameron wrote:
>>> Should move to drivers/hwmon once people are happy with it.
>>>
>>> Minimal support of simple in, curr and temp attributes
>>> so far.
>>>
>>> Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
>>> ---
>>> drivers/iio/Kconfig | 8 ++
>>> drivers/iio/Makefile | 1 +
>>> drivers/iio/iio_hwmon.c | 227 +++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 236 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>>> index 308bc97..c2f0970 100644
>>> --- a/drivers/iio/Kconfig
>>> +++ b/drivers/iio/Kconfig
>>> @@ -11,6 +11,14 @@ menuconfig IIO
>>>
>>> if IIO
>>>
>>> +config IIO_HWMON
>>> + tristate "Hwmon driver that uses channels specified via iio maps"
>>> + depends on HWMON
>>> + help
>>> + This is a platform driver that in combination with a suitable
>>> + map allows IIO devices to provide basic hwmon functionality
>>> + for those channels specified in the map.
>>> +
>>> source "drivers/iio/adc/Kconfig"
>>> source "drivers/iio/imu/Kconfig"
>>> source "drivers/iio/light/Kconfig"
>>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>>> index cfb588a..5f9c01a 100644
>>> --- a/drivers/iio/Makefile
>>> +++ b/drivers/iio/Makefile
>>> @@ -6,6 +6,7 @@ obj-y = inkern.o
>>> obj-$(CONFIG_IIO) += iio.o
>>> industrialio-y := core.o
>>>
>>> +obj-$(CONFIG_IIO_HWMON) += iio_hwmon.o
>>> obj-y += adc/
>>> obj-y += imu/
>>> obj-y += light/
>>> diff --git a/drivers/iio/iio_hwmon.c b/drivers/iio/iio_hwmon.c
>>> new file mode 100644
>>> index 0000000..b3348ad
>>> --- /dev/null
>>> +++ b/drivers/iio/iio_hwmon.c
>>> @@ -0,0 +1,227 @@
>>> +/* Hwmon client for industrial I/O devices
>>> + *
>>> + * Copyright (c) 2011 Jonathan Cameron
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License version 2 as published by
>>> + * the Free Software Foundation.
>>> + *
>>> + * Limited functionality currently supported.
>>
>> Just nitpicking ... this comment doesn't provide much value. It doesn't
>> explain the limits, nor what could be improved.
>>
>>> + */
>>> +
>>> +#include <linux/kernel.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/module.h>
>>> +#include <linux/err.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/iio/inkern.h>
>>> +#include <linux/hwmon.h>
>>> +#include <linux/hwmon-sysfs.h>
>>> +
>>> +/**
>>> + * struct iio_hwmon_state - device instance state
>>> + * @channels: filled with null terminated array of channels from iio
>>> + * @num_channels: number of channels in channels (saves counting twice)
>>> + * @hwmon_dev: associated hwmon device
>>> + * @attr_group: the group of attributes
>>> + * @attrs: null terminated array of attribute pointers.
>>> + */
>>> +struct iio_hwmon_state {
>>> + struct iio_channel **channels;
>>> + int num_channels;
>>> + struct device *hwmon_dev;
>>> + struct attribute_group attr_group;
>>> + struct attribute **attrs;
>>> +};
>>> +
>>> +/*
>>> + * Assumes that IIO and hwmon operate in the same base units.
>>> + * This is supposed to be true, but needs verification for
>>> + * new channel types.
>>> + */
>>> +static ssize_t iio_hwmon_read_val(struct device *dev,
>>> + struct device_attribute *attr,
>>> + char *buf)
>>> +{
>>> + long result;
>>> + int val, ret, scaleint, scalepart;
>>> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
>>> + struct iio_hwmon_state *state = dev_get_drvdata(dev);
>>> +
>>> + /*
>>> + * No locking between this pair, so theoretically possible
>>> + * the scale has changed.
>>> + */
>>> + ret = iio_read_channel_raw(state->channels[sattr->index],
>>> + &val);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = iio_read_channel_scale(state->channels[sattr->index],
>>> + &scaleint, &scalepart);
>>> + if (ret < 0)
>>> + return ret;
>>> + switch (ret) {
>>> + case IIO_VAL_INT:
>>> + result = val * scaleint;
>>> + break;
>>> + case IIO_VAL_INT_PLUS_MICRO:
>>> + result = (long)val * (long)scaleint +
>>> + (long)val * (long)scalepart / 1000000L;
>>> + break;
>>> + case IIO_VAL_INT_PLUS_NANO:
>>> + result = (long)val * (long)scaleint +
>>> + (long)val * (long)scalepart / 1000000000L;
>>> + break;
>>
>> Still easy to imagine that val * scalepart gets larger than 2147483647L
>> (on machines where sizeof(long) = 4) ... it will already happen if the
>> result of (val * scalepart / 1000000000) is larger than 2.
> Good point. I really ought to have done the calcs.
> If we have maximum possible value in here things will be ugly.
>
> Worst case is scalepart is 9999999999. (could be done as 1 - 0.000000001
> which would be nicer, but we don't specify a preference - from this
> discussion I am suspecting we should!)
>
> Looks like 64 bits is going to be a requirement as you say.
>>
>> What value range do you expect to see here ?
>>
>> If (val * scaleint) is already the milli-unit, scalepart would possibly
>> only address fractions of milli-units. If so, the result of (val *
>> scalepart / 1000000000L) might always be smaller than 1, ie 0.
> It certainly should be.
>> If so, for the calculation to have any value, you might be better off using
>> DIV_ROUND_CLOSEST(val * scalepart, 1000000000L).
> Good idea.
>>
>> I am a bit confused by this anyway. Since hwmon in general reports
>> milli-units, VAL_INT appears to reflect milli-units, VAL_INT_PLUS_MICRO
>> really means nano-units, and IIO_VAL_INT_PLUS_NANO really means
>> pico-units. Is this correct ?
> Micro units of the scale factor.
>
> Take my test part a max1363...
> Scale is actually 0.5 so each adc count (e.g. raw value) is 0.5millivolts.
>
> scale int here is 0,
> scale part is 500,000 (so 0.5) and it returns IIO_VAL_INT_PLUS_MICRO.
How about the following? It'll be extremely costly, but this isn't exactly
a fast path!
case IIO_VAL_INT_PLUS_MICRO:
result = (s64)val * (s64)scaleint +
div_s64((s64)val * (s64)scalepart, 1000000LL);
break;
case IIO_VAL_INT_PLUS_NANO:
result = (s64)val * (s64)scaleint +
div_s64((s64)val * (s64)scalepart, 1000000000LL);
break;
Everything should fit in there and it should give us pretty good precision.
>
>
>>
>>> + default:
>>> + return -EINVAL;
>>> + }
>>> + return sprintf(buf, "%ld\n", result);
>>> +}
>>> +
>>> +static void iio_hwmon_free_attrs(struct iio_hwmon_state *st)
>>> +{
>>> + int i;
>>> + struct sensor_device_attribute *a;
>>> + for (i = 0; i < st->num_channels; i++)
>>> + if (st->attrs[i]) {
>>> + a = to_sensor_dev_attr(
>>> + container_of(st->attrs[i],
>>> + struct device_attribute,
>>> + attr));
>>> + kfree(a);
>>> + }
>>> +}
>>> +
>>> +static int __devinit iio_hwmon_probe(struct platform_device *pdev)
>>> +{
>>> + struct iio_hwmon_state *st;
>>> + struct sensor_device_attribute *a;
>>> + int ret, i;
>>> + int in_i = 1, temp_i = 1, curr_i = 1;
>>> +
>>> + st = kzalloc(sizeof(*st), GFP_KERNEL);
>>> + if (st = NULL) {
>>> + ret = -ENOMEM;
>>> + goto error_ret;
>>> + }
>>> +
>>> + st->channels = iio_channel_get_all(&pdev->dev, NULL);
>>> + if (IS_ERR(st->channels)) {
>>> + ret = PTR_ERR(st->channels);
>>> + goto error_free_state;
>>> + }
>>> +
>>> + /* count how many attributes we have */
>>> + while (st->channels[st->num_channels])
>>> + st->num_channels++;
>>> +
>>> + st->attrs = kzalloc(sizeof(st->attrs) * (st->num_channels + 1),
>>> + GFP_KERNEL);
>>
>> Why "+ 1" ?
> Null terminated list for attribute groups. Hence the kzalloc.
>>
>> Unless I am missing something, you only use st->attrs[0] ..
>> st->attrs[st->num_channels-1].
>>
>> Thanks,
>> Guenter
>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH 5/6] IIO:hwmon interface client driver.
From: Jonathan Cameron @ 2011-10-24 10:09 UTC (permalink / raw)
To: Jonathan Cameron
Cc: guenter.roeck, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, linus.ml.walleij@gmail.com,
zdevai@gmail.com, linux@arm.linux.org.uk, arnd@arndb.de,
broonie@opensource.wolfsonmicro.com, gregkh@suse.de,
lm-sensors@lm-sensors.org, khali@linux-fr.org,
thomas.petazzoni@free-electrons.com,
maxime.ripard@free-electrons.com
In-Reply-To: <4EA03E8D.1010303@cam.ac.uk>
On 10/20/11 16:30, Jonathan Cameron wrote:
> On 10/20/11 16:12, Guenter Roeck wrote:
>> On Thu, 2011-10-20 at 05:33 -0400, Jonathan Cameron wrote:
>>> Should move to drivers/hwmon once people are happy with it.
>>>
>>> Minimal support of simple in, curr and temp attributes
>>> so far.
>>>
>>> Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
>>> ---
>>> drivers/iio/Kconfig | 8 ++
>>> drivers/iio/Makefile | 1 +
>>> drivers/iio/iio_hwmon.c | 227 +++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 236 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>>> index 308bc97..c2f0970 100644
>>> --- a/drivers/iio/Kconfig
>>> +++ b/drivers/iio/Kconfig
>>> @@ -11,6 +11,14 @@ menuconfig IIO
>>>
>>> if IIO
>>>
>>> +config IIO_HWMON
>>> + tristate "Hwmon driver that uses channels specified via iio maps"
>>> + depends on HWMON
>>> + help
>>> + This is a platform driver that in combination with a suitable
>>> + map allows IIO devices to provide basic hwmon functionality
>>> + for those channels specified in the map.
>>> +
>>> source "drivers/iio/adc/Kconfig"
>>> source "drivers/iio/imu/Kconfig"
>>> source "drivers/iio/light/Kconfig"
>>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>>> index cfb588a..5f9c01a 100644
>>> --- a/drivers/iio/Makefile
>>> +++ b/drivers/iio/Makefile
>>> @@ -6,6 +6,7 @@ obj-y = inkern.o
>>> obj-$(CONFIG_IIO) += iio.o
>>> industrialio-y := core.o
>>>
>>> +obj-$(CONFIG_IIO_HWMON) += iio_hwmon.o
>>> obj-y += adc/
>>> obj-y += imu/
>>> obj-y += light/
>>> diff --git a/drivers/iio/iio_hwmon.c b/drivers/iio/iio_hwmon.c
>>> new file mode 100644
>>> index 0000000..b3348ad
>>> --- /dev/null
>>> +++ b/drivers/iio/iio_hwmon.c
>>> @@ -0,0 +1,227 @@
>>> +/* Hwmon client for industrial I/O devices
>>> + *
>>> + * Copyright (c) 2011 Jonathan Cameron
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License version 2 as published by
>>> + * the Free Software Foundation.
>>> + *
>>> + * Limited functionality currently supported.
>>
>> Just nitpicking ... this comment doesn't provide much value. It doesn't
>> explain the limits, nor what could be improved.
>>
>>> + */
>>> +
>>> +#include <linux/kernel.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/module.h>
>>> +#include <linux/err.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/iio/inkern.h>
>>> +#include <linux/hwmon.h>
>>> +#include <linux/hwmon-sysfs.h>
>>> +
>>> +/**
>>> + * struct iio_hwmon_state - device instance state
>>> + * @channels: filled with null terminated array of channels from iio
>>> + * @num_channels: number of channels in channels (saves counting twice)
>>> + * @hwmon_dev: associated hwmon device
>>> + * @attr_group: the group of attributes
>>> + * @attrs: null terminated array of attribute pointers.
>>> + */
>>> +struct iio_hwmon_state {
>>> + struct iio_channel **channels;
>>> + int num_channels;
>>> + struct device *hwmon_dev;
>>> + struct attribute_group attr_group;
>>> + struct attribute **attrs;
>>> +};
>>> +
>>> +/*
>>> + * Assumes that IIO and hwmon operate in the same base units.
>>> + * This is supposed to be true, but needs verification for
>>> + * new channel types.
>>> + */
>>> +static ssize_t iio_hwmon_read_val(struct device *dev,
>>> + struct device_attribute *attr,
>>> + char *buf)
>>> +{
>>> + long result;
>>> + int val, ret, scaleint, scalepart;
>>> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
>>> + struct iio_hwmon_state *state = dev_get_drvdata(dev);
>>> +
>>> + /*
>>> + * No locking between this pair, so theoretically possible
>>> + * the scale has changed.
>>> + */
>>> + ret = iio_read_channel_raw(state->channels[sattr->index],
>>> + &val);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = iio_read_channel_scale(state->channels[sattr->index],
>>> + &scaleint, &scalepart);
>>> + if (ret < 0)
>>> + return ret;
>>> + switch (ret) {
>>> + case IIO_VAL_INT:
>>> + result = val * scaleint;
>>> + break;
>>> + case IIO_VAL_INT_PLUS_MICRO:
>>> + result = (long)val * (long)scaleint +
>>> + (long)val * (long)scalepart / 1000000L;
>>> + break;
>>> + case IIO_VAL_INT_PLUS_NANO:
>>> + result = (long)val * (long)scaleint +
>>> + (long)val * (long)scalepart / 1000000000L;
>>> + break;
>>
>> Still easy to imagine that val * scalepart gets larger than 2147483647L
>> (on machines where sizeof(long) = 4) ... it will already happen if the
>> result of (val * scalepart / 1000000000) is larger than 2.
> Good point. I really ought to have done the calcs.
> If we have maximum possible value in here things will be ugly.
>
> Worst case is scalepart is 9999999999. (could be done as 1 - 0.000000001
> which would be nicer, but we don't specify a preference - from this
> discussion I am suspecting we should!)
>
> Looks like 64 bits is going to be a requirement as you say.
>>
>> What value range do you expect to see here ?
>>
>> If (val * scaleint) is already the milli-unit, scalepart would possibly
>> only address fractions of milli-units. If so, the result of (val *
>> scalepart / 1000000000L) might always be smaller than 1, ie 0.
> It certainly should be.
>> If so, for the calculation to have any value, you might be better off using
>> DIV_ROUND_CLOSEST(val * scalepart, 1000000000L).
> Good idea.
>>
>> I am a bit confused by this anyway. Since hwmon in general reports
>> milli-units, VAL_INT appears to reflect milli-units, VAL_INT_PLUS_MICRO
>> really means nano-units, and IIO_VAL_INT_PLUS_NANO really means
>> pico-units. Is this correct ?
> Micro units of the scale factor.
>
> Take my test part a max1363...
> Scale is actually 0.5 so each adc count (e.g. raw value) is 0.5millivolts.
>
> scale int here is 0,
> scale part is 500,000 (so 0.5) and it returns IIO_VAL_INT_PLUS_MICRO.
How about the following? It'll be extremely costly, but this isn't exactly
a fast path!
case IIO_VAL_INT_PLUS_MICRO:
result = (s64)val * (s64)scaleint +
div_s64((s64)val * (s64)scalepart, 1000000LL);
break;
case IIO_VAL_INT_PLUS_NANO:
result = (s64)val * (s64)scaleint +
div_s64((s64)val * (s64)scalepart, 1000000000LL);
break;
Everything should fit in there and it should give us pretty good precision.
>
>
>>
>>> + default:
>>> + return -EINVAL;
>>> + }
>>> + return sprintf(buf, "%ld\n", result);
>>> +}
>>> +
>>> +static void iio_hwmon_free_attrs(struct iio_hwmon_state *st)
>>> +{
>>> + int i;
>>> + struct sensor_device_attribute *a;
>>> + for (i = 0; i < st->num_channels; i++)
>>> + if (st->attrs[i]) {
>>> + a = to_sensor_dev_attr(
>>> + container_of(st->attrs[i],
>>> + struct device_attribute,
>>> + attr));
>>> + kfree(a);
>>> + }
>>> +}
>>> +
>>> +static int __devinit iio_hwmon_probe(struct platform_device *pdev)
>>> +{
>>> + struct iio_hwmon_state *st;
>>> + struct sensor_device_attribute *a;
>>> + int ret, i;
>>> + int in_i = 1, temp_i = 1, curr_i = 1;
>>> +
>>> + st = kzalloc(sizeof(*st), GFP_KERNEL);
>>> + if (st == NULL) {
>>> + ret = -ENOMEM;
>>> + goto error_ret;
>>> + }
>>> +
>>> + st->channels = iio_channel_get_all(&pdev->dev, NULL);
>>> + if (IS_ERR(st->channels)) {
>>> + ret = PTR_ERR(st->channels);
>>> + goto error_free_state;
>>> + }
>>> +
>>> + /* count how many attributes we have */
>>> + while (st->channels[st->num_channels])
>>> + st->num_channels++;
>>> +
>>> + st->attrs = kzalloc(sizeof(st->attrs) * (st->num_channels + 1),
>>> + GFP_KERNEL);
>>
>> Why "+ 1" ?
> Null terminated list for attribute groups. Hence the kzalloc.
>>
>> Unless I am missing something, you only use st->attrs[0] ..
>> st->attrs[st->num_channels-1].
>>
>> Thanks,
>> Guenter
>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] mmc: boot partition ro lock support
From: Chris Ball @ 2011-10-24 10:08 UTC (permalink / raw)
To: Ulf Hansson
Cc: Sebastian Rasmussen, Linus Walleij, Andrei Warkentin, Per FORLIN,
Lee Jones, Johan RUDHOLM, John BECKETT, linux-mmc@vger.kernel.org
In-Reply-To: <4EA52E92.1010406@stericsson.com>
Hi Ulf,
On Mon, Oct 24 2011, Ulf Hansson wrote:
> The kernel could very much be used in manufacturing environment as
> well. Don't know if and how we should consider this.
>
> Do you think a change to an ioctl is a better alternative than sysfs?
> Then let's change to that!
Ah, we're not proposing a new ioctl for this -- we're proposing that the
perm-r/o command could be sent from a userspace binary that *uses* the
arbitrary command ioctl that we already have.
The arbitrary command ioctl is drivers/mmc/card/block.c:mmc_blk_ioctl_cmd().
Please could you send a version of the patch that supports power-on r/o
but not perm r/o, and perhaps also post userspace code for submitting
the perm r/o command through the ioctl interface? (Perhaps this code
should eventually be submitted to a disk management tool..)
Also, it looks like it's possible to set read-only for the whole device,
as well as for boot partitions. Could you update the patch to allow
setting power-on r/o for the entire card, not just the boot partitions?
> Enable boot partitions to be power and permanently read-only locked via
> a sysfs entry. There will be one sysfs entry for the main mmc device:
>
> /sys/block/mmcblkX/boot_partition_ro_lock
I don't follow why this node is necessary, instead of just having the
nodes in the mmcblkXbootY/ directories. Could you explain?
> and one for each boot partition:
>
> /sys/block/mmcblkXbootY/ro_lock
>
> The boot partitions are power or permanently locked by writing "pwr_ro"
> or "perm_ro" to one of the files.
Now that we're only having one type of r/o lock, let's do:
echo 1 > /sys/block/mmcblkXbootY/ro_lock_until_next_power_on
to lock just a boot partition, and:
echo 1 > /sys/block/mmcblkX/ro_lock_until_next_power_on
to lock the entire card (which will cover the boot partition too), with
echo 0 to unlock.
Other review comments: I noticed that your pr_*(); statements are
missing "\n"s on the end, and you should add documentation on the new
sysfs nodes to:
Documentation/mmc/mmc-dev-parts.txt
I think the overlap between your patch and Andrei's mmcblkXbootY/force_ro
node is going to be confusing -- one operates purely in the kernel and
the other is sent to the card. Do you have any proposal for making the
difference clearer?
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Paolo Bonzini @ 2011-10-24 10:08 UTC (permalink / raw)
To: Kevin Wolf; +Cc: avi, Alexander Graf, qemu-devel
In-Reply-To: <4EA535AB.3010805@redhat.com>
On 10/24/2011 11:53 AM, Kevin Wolf wrote:
>> >
>> > I'm talking about the internal driver API only. The external API is
>> > fine as is.
> Ok, so external callers don't force us to do it.
>
> Yes, we could split bdrv_flush internally into two functions for "flush
> one level to the OS" and "flush all the way down to the disk", but I'm
> not sure if this really buys us anything or just adds complexity.
I would say that:
1) the "safe" NBD and iSCSI drivers are not in-tree, but you would have to
convert those too. iSCSI uses aio, so it would be non-trivial.
2) long-term you wanted to convert raw-posix to coroutines, but in the
meanwhile your patch introduces yet another partial transition;
3) your two patches are more complex compared to something like this:
diff --git a/block.c b/block.c
index 11c7f91..1e06a8a 100644
--- a/block.c
+++ b/block.c
@@ -2908,9 +2908,19 @@ static void coroutine_fn bdrv_flush_co_entry(void *opaque)
int coroutine_fn bdrv_co_flush(BlockDriverState *bs)
{
- if (bs->open_flags & BDRV_O_NO_FLUSH) {
+ if (!bs->drv) {
return 0;
- } else if (!bs->drv) {
+ }
+
+ /* First send everything to the OS. */
+ if (bs->drv->bdrv_co_flush_metadata) {
+ int ret = bs->drv->bdrv_co_flush_metadata(bs);
+ if (ret < 0) {
+ return ret;
+ }
+ }
+
+ /* Now flush the host cache to disk if we need to. */
+ if (bs->open_flags & BDRV_O_NO_FLUSH) {
return 0;
} else if (bs->drv->bdrv_co_flush) {
return bs->drv->bdrv_co_flush(bs);
diff --git a/block/qcow2.c b/block/qcow2.c
index a181932..cd13452 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1105,7 +1105,7 @@ fail:
return ret;
}
-static int qcow2_co_flush(BlockDriverState *bs)
+static int qcow2_co_flush_metadata(BlockDriverState *bs)
{
BDRVQcowState *s = bs->opaque;
int ret;
@@ -1121,7 +1121,11 @@ static int qcow2_co_flush(BlockDriverState *bs)
return ret;
}
qemu_co_mutex_unlock(&s->lock);
+ return 0;
+}
+static int qcow2_co_flush(BlockDriverState *bs)
+{
return bdrv_co_flush(bs->file);
}
@@ -1244,6 +1248,7 @@ static BlockDriver bdrv_qcow2 = {
.bdrv_co_readv = qcow2_co_readv,
.bdrv_co_writev = qcow2_co_writev,
.bdrv_co_flush = qcow2_co_flush,
+ .bdrv_co_flush_metadata = qcow2_co_flush_metadata,
.bdrv_co_discard = qcow2_co_discard,
.bdrv_truncate = qcow2_truncate,
diff --git a/block_int.h b/block_int.h
index dac00f5..ab4ceea 100644
--- a/block_int.h
+++ b/block_int.h
@@ -84,6 +84,7 @@ struct BlockDriver {
int coroutine_fn (*bdrv_co_writev)(BlockDriverState *bs,
int64_t sector_num, int nb_sectors, QEMUIOVector *qiov);
int coroutine_fn (*bdrv_co_flush)(BlockDriverState *bs);
+ int coroutine_fn (*bdrv_co_flush_metadata)(BlockDriverState *bs);
int coroutine_fn (*bdrv_co_discard)(BlockDriverState *bs,
int64_t sector_num, int nb_sectors);
Paolo
^ permalink raw reply related
* Re: [PATCH 2/2] x86 amd_gart_64: Verify we can perform the remapping requested
From: Joerg Roedel @ 2011-10-24 10:07 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel
In-Reply-To: <m1fwir48og.fsf@fess.ebiederm.org>
On Mon, Oct 17, 2011 at 02:20:15PM -0700, Eric W. Biederman wrote:
>
> Recently I had a driver try with a peculiar 2G dma memory limit.
> The driver failed in weird and strange ways because the GART remapping
> apperture had been allocated above 2G where the driver cound not reach,
> and no error was reported when the mappings were setup.
>
> Implement gart_dma_supported to test for this problem case and to return
> and error if we can not support the remapping.
You do basically the same as for swiotlb, so it must be good :)
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
For both patches:
Acked-by: Joerg Roedel <joerg.roedel@amd.com>
> ---
> arch/x86/kernel/amd_gart_64.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
> index 8a439d3..66279cb 100644
> --- a/arch/x86/kernel/amd_gart_64.c
> +++ b/arch/x86/kernel/amd_gart_64.c
> @@ -519,6 +519,14 @@ static int gart_mapping_error(struct device *dev, dma_addr_t dma_addr)
> return (dma_addr == bad_dma_addr);
> }
>
> +static int gart_dma_supported(struct device *dev, u64 mask)
> +{
> + unsigned long iommu_max_addr = iommu_bus_base + iommu_size - 1;
> +
> + /* Fail if the gart window is too high to fit in the devices dma mask */
> + return iommu_max_addr <= mask;
> +}
> +
> static int no_agp;
>
> static __init unsigned long check_iommu_size(unsigned long aper, u64 aper_size)
> @@ -703,6 +711,7 @@ static struct dma_map_ops gart_dma_ops = {
> .alloc_coherent = gart_alloc_coherent,
> .free_coherent = gart_free_coherent,
> .mapping_error = gart_mapping_error,
> + .dma_supported = gart_dma_supported,
> };
>
> static void gart_iommu_shutdown(void)
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Nothing great was ever achieved without enthusiasm.
^ permalink raw reply
* Re: cryptodev tree on github
From: Stephen Rothwell @ 2011-10-24 10:06 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, linux-crypto
In-Reply-To: <20111021082016.GA13483@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
Hi Herbert,
On Fri, 21 Oct 2011 10:20:16 +0200 Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Sun, Sep 25, 2011 at 02:50:23PM +1000, Herbert Xu wrote:
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Are you also going to move crypto-curent?
> >
> > I'll create that soon. I'll let you know when it happens.
>
> The crypto-current tree is now up at
>
> git://github.com/herbertx/crypto.git
I have switched to that now. Please let me know if/when you switch back
to kernel.org.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.