* Re: [PATCH] ahci: add DT binding for Calxeda AHCI controller
From: Rob Herring @ 2011-10-24 14:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linux-kernel, devicetree-discuss
In-Reply-To: <4E8A6FB3.4090909@gmail.com>
Jeff,
On 10/03/2011 09:30 PM, Rob Herring wrote:
> On 09/02/2011 10:10 AM, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> Add devicetree match table to ahci platform driver for Calxeda Highbank
>> AHCI controller.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Cc: Jeff Garzik <jgarzik@pobox.com>
>> Cc: linux-ide@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>> ---
>
> Any comments on this?
>
Ping.
Can you please apply this for 3.2.
Regards,
Rob
>> .../devicetree/bindings/ata/calxeda-sata.txt | 17 +++++++++++++++++
>> drivers/ata/ahci_platform.c | 7 +++++++
>> 2 files changed, 24 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/ata/calxeda-sata.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ata/calxeda-sata.txt b/Documentation/devicetree/bindings/ata/calxeda-sata.txt
>> new file mode 100644
>> index 0000000..79caa56
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ata/calxeda-sata.txt
>> @@ -0,0 +1,17 @@
>> +* Calxeda SATA Controller
>> +
>> +SATA nodes are defined to describe on-chip Serial ATA controllers.
>> +Each SATA controller should have its own node.
>> +
>> +Required properties:
>> +- compatible : compatible list, contains "calxeda,hb-ahci"
>> +- interrupts : <interrupt mapping for SATA IRQ>
>> +- reg : <registers mapping>
>> +
>> +Example:
>> + sata@ffe08000 {
>> + compatible = "calxeda,hb-ahci";
>> + reg = <0xffe08000 0x1000>;
>> + interrupts = <115>;
>> + };
>> +
>> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
>> index 6fef1fa..9bfc970 100644
>> --- a/drivers/ata/ahci_platform.c
>> +++ b/drivers/ata/ahci_platform.c
>> @@ -171,11 +171,18 @@ static int __devexit ahci_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> +static const struct of_device_id ahci_of_match[] = {
>> + { .compatible = "calxeda,hb-ahci", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, ahci_of_match);
>> +
>> static struct platform_driver ahci_driver = {
>> .remove = __devexit_p(ahci_remove),
>> .driver = {
>> .name = "ahci",
>> .owner = THIS_MODULE,
>> + .of_match_table = ahci_of_match,
>> },
>> };
>>
>
^ permalink raw reply
* Re: [GIT] Security subsystem updates for 3.2
From: Stephen Rothwell @ 2011-10-24 14:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: James Morris, linux-security-module, linux-kernel
In-Reply-To: <CA+55aFxbh9eHYe8cPH2TaTW1t5C6C+z-Bcy+kGhR0Gt=MgMvcQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
Hi Linus,
On Mon, 24 Oct 2011 15:52:56 +0200 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> >
> > Jarkko Sakkinen (6):
> > Smack: domain transition protections (v3)
>
> So this is reverted in linux-next. I don't know why, but it's a bad
> sign. Doesn't compile?
Yeah, this:
security/smack/smack_lsm.c: In function 'smack_bprm_set_creds':
security/smack/smack_lsm.c:473:21: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function)
Caused by commit 84088ba23929 ("Smack: domain transition protections
(v3)"). PER_CLEAR_ON_SETID is defined in linux/personality.h which is not
directly included by the above file.
It appears to have been fixed in the current version of the tree by this:
Smack: compilation fix
--
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
* Re: [CONSOLIDATED PULL 11/27] pulseaudio-0.9.23: inherit perlnative to work around build on host without XML/Parser.pm
From: Richard Purdie @ 2011-10-24 14:15 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <91421698-3BCA-4B52-8C7C-AD842A2E62FB@dominion.thruhere.net>
On Mon, 2011-10-24 at 15:19 +0200, Koen Kooi wrote:
> Op 24 okt. 2011, om 15:15 heeft Richard Purdie het volgende geschreven:
>
> > On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> >> From: Martin Jansa <Martin.Jansa@gmail.com>
> >>
> >> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >> ---
> >> .../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> >> index 33f5e15..4ac2418 100644
> >> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> >> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> >> @@ -4,7 +4,7 @@ PR = "r5"
> >>
> >> DEPENDS += "gdbm speex"
> >>
> >> -inherit gettext
> >> +inherit gettext perlnative
> >
> > This doesn't look right. If we need xmlparser, we should state that in
> > DEPENDS. If that is added to DEPENDS, I'm not sure we still need the
> > inherit of perlnative?
>
> If you need xmlparser during the build you almost always need the
> perlnative wrapper as well :(
I was under the impression that we'd fixed most of those issues :/. It
could well be a valid dependency in this case so I'll take the patch
with the added DEPENDS.
Cheers,
Richard
^ permalink raw reply
* Re: [patch net-next V4] net: introduce ethernet teaming device
From: Paul E. McKenney @ 2011-10-24 14:11 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Jiri Pirko, netdev, davem, eric.dumazet, bhutchings, shemminger,
fubar, andy, tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl,
jzupka, Dipankar Sarma
In-Reply-To: <20111024130918.GB24473@synalogic.ca>
On Mon, Oct 24, 2011 at 09:09:19AM -0400, Benjamin Poirier wrote:
> On 11/10/24 10:13, Jiri Pirko wrote:
> > This patch introduces new network device called team. It supposes to be
> > very fast, simple, userspace-driven alternative to existing bonding
> > driver.
> >
> > Userspace library called libteam with couple of demo apps is available
> > here:
> > https://github.com/jpirko/libteam
> > Note it's still in its dipers atm.
> >
> > team<->libteam use generic netlink for communication. That and rtnl
> > suppose to be the only way to configure team device, no sysfs etc.
> >
> > Python binding basis for libteam was recently introduced (some need
> > still need to be done on it though). Daemon providing arpmon/miimon
> > active-backup functionality will be introduced shortly.
> > All what's necessary is already implemented in kernel team driver.
> >
> > Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> >
> > v3->v4:
> > - remove redundant synchronize_rcu from __team_change_mode()
> > - revert "set and clear of mode_ops happens per pointer, not per
> > byte"
> > - extend comment of function __team_change_mode()
> >
> > v2->v3:
> > - team_change_mtu() user rcu version of list traversal to unwind
> > - set and clear of mode_ops happens per pointer, not per byte
> > - port hashlist changed to be embedded into team structure
> > - error branch in team_port_enter() does cleanup now
> > - fixed rtln->rtnl
> >
> > v1->v2:
> > - modes are made as modules. Makes team more modular and
> > extendable.
> > - several commenters' nitpicks found on v1 were fixed
> > - several other bugs were fixed.
> > - note I ignored Eric's comment about roundrobin port selector
> > as Eric's way may be easily implemented as another mode (mode
> > "random") in future.
> > ---
> > Documentation/networking/team.txt | 2 +
> > MAINTAINERS | 7 +
> > drivers/net/Kconfig | 2 +
> > drivers/net/Makefile | 1 +
> > drivers/net/team/Kconfig | 38 +
> > drivers/net/team/Makefile | 7 +
> > drivers/net/team/team.c | 1573 +++++++++++++++++++++++++++++
> > drivers/net/team/team_mode_activebackup.c | 152 +++
> > drivers/net/team/team_mode_roundrobin.c | 107 ++
> > include/linux/Kbuild | 1 +
> > include/linux/if.h | 1 +
> > include/linux/if_team.h | 231 +++++
> > include/linux/rculist.h | 14 +
>
> I think you're missing some CC's for the modifications to this file.
> I've taken the liberty of adding Dipankar and Paul to the discussion.
Thank you, and please see below.
> > 13 files changed, 2136 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/networking/team.txt
> > create mode 100644 drivers/net/team/Kconfig
> > create mode 100644 drivers/net/team/Makefile
> > create mode 100644 drivers/net/team/team.c
> > create mode 100644 drivers/net/team/team_mode_activebackup.c
> > create mode 100644 drivers/net/team/team_mode_roundrobin.c
> > create mode 100644 include/linux/if_team.h
> >
>
> [...]
>
> > diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
> > new file mode 100644
> > index 0000000..acfef4c
> > --- /dev/null
> > +++ b/drivers/net/team/team.c
> > +
> [...]
> > +static int team_change_mtu(struct net_device *dev, int new_mtu)
> > +{
> > + struct team *team = netdev_priv(dev);
> > + struct team_port *port;
> > + int err;
> > +
> > + rcu_read_lock();
> > + list_for_each_entry_rcu(port, &team->port_list, list) {
> > + err = dev_set_mtu(port->dev, new_mtu);
> > + if (err) {
> > + netdev_err(dev, "Device %s failed to change mtu",
> > + port->dev->name);
> > + goto unwind;
> > + }
> > + }
> > + rcu_read_unlock();
> > +
> > + dev->mtu = new_mtu;
> > +
> > + return 0;
> > +
> > +unwind:
> > + list_for_each_entry_continue_reverse_rcu(port, &team->port_list, list)
> > + dev_set_mtu(port->dev, dev->mtu);
> > +
> > + rcu_read_unlock();
> > + return err;
> > +}
> > +
> > +
>
> [...]
>
> > diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> > index d079290..7586b2c 100644
> > --- a/include/linux/rculist.h
> > +++ b/include/linux/rculist.h
> > @@ -288,6 +288,20 @@ static inline void list_splice_init_rcu(struct list_head *list,
> > pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
> >
> > /**
> > + * list_for_each_entry_continue_reverse_rcu - iterate backwards from the given point
> > + * @pos: the type * to use as a loop cursor.
> > + * @head: the head for your list.
> > + * @member: the name of the list_struct within the struct.
> > + *
> > + * Start to iterate over list of given type backwards, continuing after
> > + * the current position.
> > + */
> > +#define list_for_each_entry_continue_reverse_rcu(pos, head, member) \
> > + for (pos = list_entry_rcu(pos->member.prev, typeof(*pos), member); \
> > + &pos->member != (head); \
> > + pos = list_entry_rcu(pos->member.prev, typeof(*pos), member))
> > +
>
> rcu lists can be modified while they are traversed with *_rcu()
> primitives. This benefit comes with the constraint that they may only be
> traversed forwards. This is implicit in the choice of *_rcu()
> list-traversal primitives: they only go forwards.
>
> You suggest to add a backwards rcu list-traversal primitive. But
> consider what happens in this sequence:
>
> CPU0 CPU1
> list_for_each_entry_continue_reverse_rcu(...)
> pos = list_entry_rcu(pos->member.prev, typeof(*pos), member)
> list_del_rcu(&pos->member)
> { (&pos->member)->prev = LIST_POISON2 }
> pos = list_entry_rcu(pos->member.prev, typeof(*pos), member)
> = container_of(LIST_POISON2, typeof(*pos), member)
> do_something(*pos)
> BAM!
>
> Going back to the problem you're trying to solve in team_change_mtu(),
> I think you could either:
> 1) take team->lock instead of rcu_read_lock() throughout this particular
> function
> 2) save each deleted element in a separate list on the side in case it's
> necessary to roll back
> 3) remove the rcu double locking, rely on rtnl and add some
> ASSERT_RTNL() if desired. You've said that you don't want to rely on
> rtnl and you want to use separate locking but I fail to see what
> advantage that brings to balance out the extra complexity in code and
> execution? Please clarify this.
Indeed -- the list_for_each_entry_continue_reverse_rcu() implementation
above would only work if elements were never deleted from the list.
But people would miss that fact, resulting in list-poison oopses.
Furthermore, even if you avoid the poisoning, there is no guarantee
that you will see the same objects in reverse that you saw going
forward because some might have been added or deleted in the meantime.
So please take some other approach. For example, if the list has a
fixed upper bound, perhaps just keeping track of what elements you
visited would be workable.
Thanx, Paul
> Thanks,
> -Ben
>
> > +/**
> > * hlist_del_rcu - deletes entry from hash list without re-initialization
> > * @n: the element to delete from the hash list.
> > *
> > --
> > 1.7.6
> >
>
^ permalink raw reply
* Re: [PATCH 2/2] pulseaudio: inherit perlnative
From: Richard Purdie @ 2011-10-24 14:17 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319380267-29794-2-git-send-email-raj.khem@gmail.com>
On Sun, 2011-10-23 at 07:31 -0700, Khem Raj wrote:
> manpage generatition uses xmltoman utility
> which inturn uses xml-parser. So we add
> libxml-parser-perl-native to DEPENDS and also
> inherit perlnative so it does not use the one
> from build host
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> .../pulseaudio/pulseaudio_0.9.23.bb | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [CONSOLIDATED PULL 20/27] libtool: Upgrade from 2.4 -> 2.4.2
From: Koen Kooi @ 2011-10-24 14:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319465445.25011.18.camel@ted>
Op 24 okt. 2011, om 16:10 heeft Richard Purdie het volgende geschreven:
> On Mon, 2011-10-24 at 15:37 +0200, Koen Kooi wrote:
>> Op 24 okt. 2011, om 15:34 heeft Richard Purdie het volgende geschreven:
>>
>>> On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
>>>> From: Khem Raj <raj.khem@gmail.com>
>>>>
>>>> Adjust prefix.patch and delete resolve-sysroot.patch
>>>> since its already applied upstream
>>>>
>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>> ---
>>>> .../libtool/{libtool.inc => libtool-2.4.2.inc} | 26 +++++++++---
>>>> meta/recipes-devtools/libtool/libtool-2.4.inc | 13 ------
>>>> ...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} | 2 +-
>>>> ...btool-native_2.4.bb => libtool-native_2.4.2.bb} | 2 +-
>>>> ...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} | 2 +-
>>>> meta/recipes-devtools/libtool/libtool/prefix.patch | 46 ++++++++++----------
>>>> .../libtool/libtool/resolve-sysroot.patch | 42 ------------------
>>>> .../libtool/{libtool_2.4.bb => libtool_2.4.2.bb} | 2 +-
>>>> 8 files changed, 47 insertions(+), 88 deletions(-)
>>>> rename meta/recipes-devtools/libtool/{libtool.inc => libtool-2.4.2.inc} (57%)
>>>> delete mode 100644 meta/recipes-devtools/libtool/libtool-2.4.inc
>>>> rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} (98%)
>>>> rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb => libtool-native_2.4.2.bb} (96%)
>>>> rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} (97%)
>>>> delete mode 100644 meta/recipes-devtools/libtool/libtool/resolve-sysroot.patch
>>>> rename meta/recipes-devtools/libtool/{libtool_2.4.bb => libtool_2.4.2.bb} (94%)
>>>>
>>>> diff --git a/meta/recipes-devtools/libtool/libtool.inc b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>> similarity index 57%
>>>> rename from meta/recipes-devtools/libtool/libtool.inc
>>>> rename to meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>> index ef9095b..1f652ef 100644
>>>> --- a/meta/recipes-devtools/libtool/libtool.inc
>>>> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>> @@ -1,4 +1,3 @@
>>>> -SUMMARY = "Generic library support script"
>>>
>>> Why drop the SUMMARY field?
>>
>> What's the difference between SUMMARY and DESCRIPTION? And what happens if both are set?
>
> SUMMARY is a one line 74? character summary of the package, DESCRIPTION
> is a multiple line stream of text containing a more verbose description.
> What happens to the data is package backend specific, I know RPM has
> uses for both. There was definitely discussion about this on the mailing
> list at the time, I'm not sure what if anything made it into the manuals
> but if its not there it should be added.
It seems to get OR'd:
meta/classes/package_deb.bbclass: summary = bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or "."
package_deb.bbclass: description = bb.data.getVar('DESCRIPTION', localdata, True) or "."
meta/classes/package_ipk.bbclass: summary = bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or "."
package_ipk.bbclass: description = bb.data.getVar('DESCRIPTION', localdata, True) or "."
meta/classes/package_rpm.bbclass: srcsummary = (bb.data.getVar('SUMMARY', d, True) or bb.data.getVar('DESCRIPTION', d, True) or ".")
package_rpm.bbclass: srcdescription = bb.data.getVar('DESCRIPTION', d, True) or "."
regards,
Koen
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Michael S. Tsirkin @ 2011-10-24 14:25 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Avi Kivity, Marcelo Tosatti, kvm
In-Reply-To: <4EA563FD.5060308@siemens.com>
On Mon, Oct 24, 2011 at 03:11:25PM +0200, Jan Kiszka wrote:
> On 2011-10-24 14:43, Michael S. Tsirkin wrote:
> > On Mon, Oct 24, 2011 at 02:06:08PM +0200, Jan Kiszka wrote:
> >> On 2011-10-24 13:09, Avi Kivity wrote:
> >>> On 10/24/2011 12:19 PM, Jan Kiszka wrote:
> >>>>>
> >>>>> 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.
> >>>>
> >>>
> >>> Only if those devices are in the same process (or have access to the
> >>> vmfd). Interrupt routing together with irqfd allows you to disaggregate
> >>> the device model. Instead of providing a competing implementation with
> >>> new limitations, we need to remove the limitations of the old
> >>> implementation.
> >>
> >> That depends on where we do the cut. Currently we let the IRQ source
> >> signal an abstract edge on a pre-allocated pseudo IRQ line. But we
> >> cannot build correct MSI-X on top of the current irqfd model as we lack
> >> the level information (for PBA emulation). *)
> >
> >
> > I don't agree here. IMO PBA emulation would need to
> > clear pending bits on interrupt status register read.
> > So clearing pending bits could be done by ioctl from qemu
> > while setting them would be done from irqfd.
>
> How should QEMU know if the reason for "pending" has been cleared at
> device level if the device is outside the scope of QEMU? This model only
> works for PV devices when you agree that spurious IRQs are OK.
A read or irq status clears pending in the same way it clears
irq line for level. I don't think this generates spurious irqs. Yes it
only works for PV.
For assigned devices, the only way I see to implement PBA
correctly is by masking the vector in the device
and looking at the actual pending bit.
> >
> >> So we either need to
> >> extend the existing model anyway -- or push per-vector masking back to
> >> the IRQ source. In the latter case, it would be a very good chance to
> >> give up on limited pseudo GSIs with static routes and do MSI messaging
> >> from external IRQ sources to KVM directly.
> >> But all those considerations affect different APIs than what I'm
> >> proposing here. We will always need a way to inject MSIs in the context
> >> of the VM as there will always be scenarios where devices are better run
> >> in that very same context, for performance or simplicity or whatever
> >> reasons. E.g., I could imagine that one would like to execute an
> >> emulated IRQ remapper rather in the hypervisor context than
> >> "over-microkernelized" in a separate process.
> >>
> >> Jan
> >>
> >> *) Realized this while trying to generalize the proposed MSI-X MMIO
> >> acceleration for assigned devices to arbitrary device models, vhost-net,
> >
> > I'm actually working on a qemu patch to get pba emulation working correctly.
> > I think it's doable with existing irqfd.
>
> irqfd has no notion of level. You can only communicate a rising edge and
> then need a side channel for the state of the edge reason.
True. But we only need that for PBA read which is unused ATM.
So kvm can just send the read to userspace, have qemu query
vfio or whatever.
> >
> >> and specifically vfio.
> >
> > Interesting. How would you clear the pseudo interrupt level?
>
> Ideally: not at all (for MSI). If we manage the mask at device level, we
> only need to send the message if there is actually something to deliver
> to the interrupt controller and masked input events would be lost on
> real HW as well.
Not sure I understand. we certainly shouldn't send masked
interrupts to the APIC if for no other reason that
the message value is invalid while masked.
> That said, we still need to address the irqfd level topic for the finite
> amount of legacy interrupt lines. If a line is masked at an IRQ
> controller, the device need to keep the controller up to date /wrt to
> the line state, or the controller has to poll the current state on
> unmask to avoid spurious injections.
>
> Jan
Yes, level interrupts are tricky.
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: Channel-less IIO events
From: Jonathan Cameron @ 2011-10-24 14:25 UTC (permalink / raw)
To: Lars-Peter Clausen; +Cc: linux-iio@vger.kernel.org
In-Reply-To: <4EA56C67.7020203@metafoo.de>
On 10/24/11 14:47, Lars-Peter Clausen wrote:
> Hi,
>
> Some chips generate events which don't really map to a channel, but are
> rather chip global. For example over-temperature events.
That one is a channel.
> Do you think this is something we should add support for or should we rather
> use a dummy channel, which doesn't report any actual values, for propagating
> the event?
Yup, have a temp channel for that one. Conceptually you might have two chips
that are otherwise identical but one has a readable temp channel, the other
doesn't. Userspace that is interested only in events won't care about
this difference. Also we want to report what the conditions are as if it were
a channel we could read. We want to know at what temperature this occurs.
There are others events such as loss of tracking / wire out for the resolvers,
but they so far have always corresponded to 'gah, it's all gone wrong' events.
Last time I asked more generally about this, Alan Cox suggested using the
signals typically employed for network sockets. General view is we didn't
want them coming through our normal event path and for example being blocked
behind the handling of another event. I then got bogged down with this
in kernel interface stuff so haven't looked at it again.
>
> My idea for supporting channel-less events is to add a event_mask to struct
> iio_info, which would be used just like a channels event_mask, but there
> would be no index for the sysfs attributes and for events we would set the
> event number to 0xffff.
Could you give more examples? The temp one to my mind definitely needs a
channel, perhaps others do not? I am not against in principal but not
yet certain exactly when this would make sense...
>
> Thanks
> - Lars
>
^ permalink raw reply
* Re: [CONSOLIDATED PULL 11/27] pulseaudio-0.9.23: inherit perlnative to work around build on host without XML/Parser.pm
From: Richard Purdie @ 2011-10-24 14:19 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111024132405.GB3602@jama.jama.net>
On Mon, 2011-10-24 at 15:24 +0200, Martin Jansa wrote:
> On Mon, Oct 24, 2011 at 02:15:57PM +0100, Richard Purdie wrote:
> > On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> > > From: Martin Jansa <Martin.Jansa@gmail.com>
> > >
> > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > ---
> > > .../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > index 33f5e15..4ac2418 100644
> > > --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > @@ -4,7 +4,7 @@ PR = "r5"
> > >
> > > DEPENDS += "gdbm speex"
> > >
> > > -inherit gettext
> > > +inherit gettext perlnative
> >
> > This doesn't look right. If we need xmlparser, we should state that in
> > DEPENDS. If that is added to DEPENDS, I'm not sure we still need the
> > inherit of perlnative?
>
> Yes I've forgot to put it in DEPENDS, khem sent version where he is
> adding this inherit and DEPENDs..
>
> but both are needed and only work arounds because build is calling perl
> (not env perl) and perlnative helps to put perl from perl-native before
> perl from host in PATH.
>
> Reported here:
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-October/011323.html
>
> And I've sent this as work around before I'll fill oe-core bug report or
> someone updates it to 1.1 and maybe fix it too.
I've taken Khem's version of this so that should help address this
problem.
Cheers,
Richard
^ permalink raw reply
* Re: [dm-crypt] [RFC] dm-crypt and hardware-optimized crypto modules
From: Arno Wagner @ 2011-10-24 14:25 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <4EA555F1.9090506@freesources.org>
On Mon, Oct 24, 2011 at 02:11:29PM +0200, Jonas Meurer wrote:
> Am 24.10.2011 08:21, schrieb Arno Wagner:
> > Hi Jonas,
>
> Hey Arno,
>
> > the definite authority on this is Milan, but as far as I understand
> > module autoloading, as long as an implementation for a requested
> > cipher is already loaded, that will be used. Now, I expect it would
> > be possible to not build the normal AES module and thereby have the
> > HW-supported AES module loade automatically when needed. As the
> > Debian distro-kernel cannot know HW-support would be there, it
> > obviously defaults to the software implementation.
>
> Nope, the Debian distro-kernel has software implementation built into
> the kernel, and hardware-accelerated drivers built as modules. So
> according to Milans answers, the kernel crypto engine should load and
> use the hardware-optimised drivers in case they're supported.
Hmm. If the software-version is already compiled-in, that could
prevent auto-loading of the hw-version. I would expect that you
need both as modules or both compiled-in. Should be easy to test
though.
> > AFAIK, if both HW and SW support are loaded, HW support is used as
> > default. I think there is some kind of priority system in place.
> > But I am really only guessing here.
>
> I guess you're correct here ;)
>
> > I see two ways around this:
> >
> > 1. Load the HW module manually (or scripted). While I have not used
> > a Debian Distro kernel for a long time, I think adding the
> > HW-module to /etc/modules should accomplish that. Noneed to mess
> > with the initrd, unless possibly if you have encrypted root.
> >
> > 2. Roll your own kernel, possibly with HW support statically
> > compiled in. I have used Debian with kernels from kernel.org and
> > module-support turned off with good success for about 10 years now.
> > (I don't like initrds. Good for distros, but they complicate things
> > and complexity is the enemy of reliablity and efficiency. Also, I
> > like to mess around with my installatons and initrds make that
> > harder. I also do not like to use kernel modules very much,
> > although it is definitely good that they are there.)
> >
> > To use your own kernel with Debian, just boot it and tell it the
> > root partition. Of course you have to make sure it somehow has the
> > drivers it needs to fnd and mount the root partition.
>
> As I'm the maintainer of cryptsetup in Debian, I'm searching for a
> solution for default setups.
Ah, sorry. That gives you a different perspective obviously.
> I know how to manually tweak setups to
> use the hardware-optimized crypto drivers. But I need a solution for
> the default setup with default distro-kernel. Thus building custom
> kernels is out of scope in my case.
I can see that, yes.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply
* [PATCH] dt: Add empty of_match_node() macro
From: Grant Likely @ 2011-10-24 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319450012-13033-1-git-send-email-nicolas.ferre@atmel.com>
On Mon, Oct 24, 2011 at 11:53:32AM +0200, Nicolas Ferre wrote:
> Add an empty macro for of_match_node() that will save
> some '#ifdef CONFIG_OF' for non-dt builds.
>
> I have chosen to use a macro instead of a function to
> be able to avoid defining the first parameter.
> In fact, this "struct of_device_id *" first parameter
> is usualy not defined as well on non-dt builds.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
After private discussion, yes this is okay. I've picked it up.
g.
> ---
> include/linux/of.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 736b747..92c40a1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -303,6 +303,7 @@ static inline struct device_node *of_parse_phandle(struct device_node *np,
> }
>
> #define of_match_ptr(_ptr) NULL
> +#define of_match_node(_matches, _node) NULL
> #endif /* CONFIG_OF */
>
> static inline int of_property_read_u32(const struct device_node *np,
> --
> 1.7.5.4
>
^ permalink raw reply
* Re: [PATCH] dt: Add empty of_match_node() macro
From: Grant Likely @ 2011-10-24 14:25 UTC (permalink / raw)
To: Nicolas Ferre
Cc: robherring2, linux-kernel, linux-arm-kernel, devicetree-discuss
In-Reply-To: <1319450012-13033-1-git-send-email-nicolas.ferre@atmel.com>
On Mon, Oct 24, 2011 at 11:53:32AM +0200, Nicolas Ferre wrote:
> Add an empty macro for of_match_node() that will save
> some '#ifdef CONFIG_OF' for non-dt builds.
>
> I have chosen to use a macro instead of a function to
> be able to avoid defining the first parameter.
> In fact, this "struct of_device_id *" first parameter
> is usualy not defined as well on non-dt builds.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
After private discussion, yes this is okay. I've picked it up.
g.
> ---
> include/linux/of.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 736b747..92c40a1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -303,6 +303,7 @@ static inline struct device_node *of_parse_phandle(struct device_node *np,
> }
>
> #define of_match_ptr(_ptr) NULL
> +#define of_match_node(_matches, _node) NULL
> #endif /* CONFIG_OF */
>
> static inline int of_property_read_u32(const struct device_node *np,
> --
> 1.7.5.4
>
^ permalink raw reply
* Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
From: Dave Anderson @ 2011-10-24 14:25 UTC (permalink / raw)
To: Wen Congyang
Cc: Jan Kiszka, Luiz Capitulino, qemu-devel, KAMEZAWA Hiroyuki,
Richard W.M. Jones
In-Reply-To: <4EA4CC7E.5000307@cn.fujitsu.com>
----- Original Message -----
> The question is that: 'virsh dump' can not be used when host pci device
> is used by guest. We are discussing how to fix the problem. We have determined
> that introduce a new monitor command dump. Jan suggested that the core file's
> format is gdb standard core format. Does crash support such format? If no,
> is it possible to support such format?
If you are talking about an ELF core dump of the user-space qemu-kvm process
running on the host, then it's certainly not supported.
As to whether it's possible, I suppose it could be done if a phyical-memory-read
function could be created for it, similar to what I asked about for live analysis
of a guest kernel run on/from the KVM host.
Dave
^ permalink raw reply
* Re: [PATCH V2 02/10] Introduce HostPCIDevice to access a pci device on the host.
From: Anthony PERARD @ 2011-10-24 14:25 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201136590.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 11:57, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Oct 2011, Anthony PERARD wrote:
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> Makefile.target | 1 +
>> hw/host-pci-device.c | 245 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> hw/host-pci-device.h | 75 +++++++++++++++
>> 3 files changed, 321 insertions(+), 0 deletions(-)
>> create mode 100644 hw/host-pci-device.c
>> create mode 100644 hw/host-pci-device.h
>>
>> diff --git a/Makefile.target b/Makefile.target
>> index c518103..ca3420d 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -209,6 +209,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>> obj-i386-$(CONFIG_XEN) += xen_platform.o
>>
>> # Xen PCI Passthrough
>> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>>
>> # Inter-VM PCI shared memory
>> CONFIG_IVSHMEM =
>> diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
>> new file mode 100644
>> index 0000000..0f25fcf
>> --- /dev/null
>> +++ b/hw/host-pci-device.c
>> @@ -0,0 +1,245 @@
>> +/*
>> + * Copyright (C) 2011 Citrix Ltd.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2. See
>> + * the COPYING file in the top-level directory.
>> + *
>> + */
>> +
>> +#include "qemu-common.h"
>> +#include "host-pci-device.h"
>> +
>> +static int path_to(const HostPCIDevice *d,
>> + const char *name, char *buf, ssize_t size)
>> +{
>> + return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
>> + d->domain, d->bus, d->dev, d->func, name);
>> +}
>> +
>> +static int get_resource(HostPCIDevice *d)
>> +{
>> + int i, rc = 0;
>> + FILE *f;
>> + char path[PATH_MAX];
>> + unsigned long long start, end, flags, size;
>> +
>> + path_to(d, "resource", path, sizeof (path));
>> + f = fopen(path, "r");
>> + if (!f) {
>> + fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
>> + return -1;
>
> it would be better to return a proper error code, rather than just -1
probably -errno will do it.
>> + }
>> +
>> + for (i = 0; i < PCI_NUM_REGIONS; i++) {
>> + if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
>> + fprintf(stderr, "Error: Syntax error in %s\n", path);
>> + rc = -1;
>
> Ditto
probably 1 with a define on the top of the file.
>> + break;
>> + }
>> + if (start) {
>> + size = end - start + 1;
>> + } else {
>> + size = 0;
>> + }
>> +
>> + if (i < PCI_ROM_SLOT) {
>> + d->io_regions[i].base_addr = start;
>> + d->io_regions[i].size = size;
>> + d->io_regions[i].flags = flags;
>> + } else {
>> + d->rom.base_addr = start;
>> + d->rom.size = size;
>> + d->rom.flags = flags;
>> + }
>> + }
>> +
>> + fclose(f);
>> + return rc;
>> +}
[...]
>> +
>> +uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
>> +{
>> + uint32_t header = 0;
>> + int max_cap = 480;
>> + int pos = 0x100;
>
> could you used some defined constants here?
Yes, I will.
>> + do {
>> + header = host_pci_get_long(d, pos);
>> + /*
>> + * If we have no capabilities, this is indicated by cap ID,
>> + * cap version and next pointer all being 0.
>> + */
>> + if (header == 0) {
>> + break;
>> + }
>> +
>> + if (PCI_EXT_CAP_ID(header) == cap) {
>> + return pos;
>> + }
>> +
>> + pos = PCI_EXT_CAP_NEXT(header);
>> + if (pos < 0x100) {
>> + break;
>> + }
>> +
>> + max_cap--;
>> + } while (max_cap > 0);
>> +
>> + return 0;
>> +}
--
Anthony PERARD
^ permalink raw reply
* Where is the getent(1) man page source?
From: Mark R Bannister @ 2011-10-24 14:26 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, espy-8fiUuRrzOP0dnm+yROfE0A
The getent.c source code is in glibc, so I'd expect to find the getent.1 man page
in the Linux man-pages project. But it's not there. Where is it? I'd like to
make it more informative.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V2 02/10] Introduce HostPCIDevice to access a pci device on the host.
From: Anthony PERARD @ 2011-10-24 14:25 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201136590.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 11:57, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Oct 2011, Anthony PERARD wrote:
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> Makefile.target | 1 +
>> hw/host-pci-device.c | 245 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> hw/host-pci-device.h | 75 +++++++++++++++
>> 3 files changed, 321 insertions(+), 0 deletions(-)
>> create mode 100644 hw/host-pci-device.c
>> create mode 100644 hw/host-pci-device.h
>>
>> diff --git a/Makefile.target b/Makefile.target
>> index c518103..ca3420d 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -209,6 +209,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>> obj-i386-$(CONFIG_XEN) += xen_platform.o
>>
>> # Xen PCI Passthrough
>> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>>
>> # Inter-VM PCI shared memory
>> CONFIG_IVSHMEM =
>> diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
>> new file mode 100644
>> index 0000000..0f25fcf
>> --- /dev/null
>> +++ b/hw/host-pci-device.c
>> @@ -0,0 +1,245 @@
>> +/*
>> + * Copyright (C) 2011 Citrix Ltd.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2. See
>> + * the COPYING file in the top-level directory.
>> + *
>> + */
>> +
>> +#include "qemu-common.h"
>> +#include "host-pci-device.h"
>> +
>> +static int path_to(const HostPCIDevice *d,
>> + const char *name, char *buf, ssize_t size)
>> +{
>> + return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
>> + d->domain, d->bus, d->dev, d->func, name);
>> +}
>> +
>> +static int get_resource(HostPCIDevice *d)
>> +{
>> + int i, rc = 0;
>> + FILE *f;
>> + char path[PATH_MAX];
>> + unsigned long long start, end, flags, size;
>> +
>> + path_to(d, "resource", path, sizeof (path));
>> + f = fopen(path, "r");
>> + if (!f) {
>> + fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
>> + return -1;
>
> it would be better to return a proper error code, rather than just -1
probably -errno will do it.
>> + }
>> +
>> + for (i = 0; i < PCI_NUM_REGIONS; i++) {
>> + if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
>> + fprintf(stderr, "Error: Syntax error in %s\n", path);
>> + rc = -1;
>
> Ditto
probably 1 with a define on the top of the file.
>> + break;
>> + }
>> + if (start) {
>> + size = end - start + 1;
>> + } else {
>> + size = 0;
>> + }
>> +
>> + if (i < PCI_ROM_SLOT) {
>> + d->io_regions[i].base_addr = start;
>> + d->io_regions[i].size = size;
>> + d->io_regions[i].flags = flags;
>> + } else {
>> + d->rom.base_addr = start;
>> + d->rom.size = size;
>> + d->rom.flags = flags;
>> + }
>> + }
>> +
>> + fclose(f);
>> + return rc;
>> +}
[...]
>> +
>> +uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
>> +{
>> + uint32_t header = 0;
>> + int max_cap = 480;
>> + int pos = 0x100;
>
> could you used some defined constants here?
Yes, I will.
>> + do {
>> + header = host_pci_get_long(d, pos);
>> + /*
>> + * If we have no capabilities, this is indicated by cap ID,
>> + * cap version and next pointer all being 0.
>> + */
>> + if (header == 0) {
>> + break;
>> + }
>> +
>> + if (PCI_EXT_CAP_ID(header) == cap) {
>> + return pos;
>> + }
>> +
>> + pos = PCI_EXT_CAP_NEXT(header);
>> + if (pos < 0x100) {
>> + break;
>> + }
>> +
>> + max_cap--;
>> + } while (max_cap > 0);
>> +
>> + return 0;
>> +}
--
Anthony PERARD
^ permalink raw reply
* Re: [22/27] VFS: Fix automount for negative autofs dentries
From: Greg KH @ 2011-10-24 14:22 UTC (permalink / raw)
To: Miklos Szeredi
Cc: Greg KH, Linus Torvalds, David Howells, linux-kernel, stable,
stable-review, akpm, alan, Ian Kent, Al Viro, Chuck Ebbert,
Trond Myklebust
In-Reply-To: <87pqhnifew.fsf@tucsk.pomaz.szeredi.hu>
On Sun, Oct 23, 2011 at 11:09:11PM +0200, Miklos Szeredi wrote:
> Greg KH <gregkh@suse.de> writes:
>
> > On Sun, Oct 23, 2011 at 10:35:14AM +0300, Linus Torvalds wrote:
> >> This one is debatable.
> >>
> >> I think it also wants
> >>
> >> - commit 0ec26fd0698285b31248e34bf1abb022c00f23d6 (with
> >> LOOKUP_PARENT->LOOKUP_CONTINUE too)
> >
> > Really? I thought I dropped this one from the last stable release due
> > to problems with it, or does this patch here, and the one you mention
> > below, resolve those issues?
> >
> >> - commit d94c177beeb4469cd4f6e83354ab0223353e98ed (to get the few
> >> other cases right too)
> >>
> >> anything else I missed?
> >
> > Ok, that makes a bit more sense, I'll add these if David and Miklos
> > agree that they are ok to add here. David and Miklos?
>
> IMO they are OK to add as long as they are both added.
>
> Last time the first one had to be backed out because Linus wasn't
> totally comfortable with the other one going into -stable until it got
> some testing in 3.1. Or at least that's how I understood (or
> misunderstood).
Ok, I tried applying these patches, but they didn't apply. I tried
digging the patches out of the suse kernel tree, but they didn't seem to
include all of the needed ones here.
So, I'm going to drop this patch from the 3.0.8 release, can someone
please send me the needed patches, backported to 3.0, so that I know
they are working properly?
thanks,
greg k-h
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V2 08/10] Introduce Xen PCI Passthrough, qdevice (1/3)
From: Anthony PERARD @ 2011-10-24 14:29 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201141280.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 11:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> + if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
>> + qemu_mod_timer(s->pm_state->pm_timer,
>> + qemu_get_clock_ms(rt_clock) + s->pm_state->pm_delay);
>> + }
>
> where is this allocated?
The allocation is in the next patch, the long file that handle the config space.
--
Anthony PERARD
^ permalink raw reply
* Re: [GIT] Security subsystem updates for 3.2
From: James Morris @ 2011-10-24 14:30 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linus Torvalds, linux-security-module, linux-kernel
In-Reply-To: <20111025012003.43d3847ec1284f68e79f9948@canb.auug.org.au>
On Tue, 25 Oct 2011, Stephen Rothwell wrote:
> > So this is reverted in linux-next. I don't know why, but it's a bad
> > sign. Doesn't compile?
>
> Yeah, this:
>
> security/smack/smack_lsm.c: In function 'smack_bprm_set_creds':
> security/smack/smack_lsm.c:473:21: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function)
>
> Caused by commit 84088ba23929 ("Smack: domain transition protections
> (v3)"). PER_CLEAR_ON_SETID is defined in linux/personality.h which is not
> directly included by the above file.
>
> It appears to have been fixed in the current version of the tree by this:
>
> Smack: compilation fix
Yep, that's the fix for it.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [CONSOLIDATED PULL 20/27] libtool: Upgrade from 2.4 -> 2.4.2
From: Richard Purdie @ 2011-10-24 14:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <C0347AB9-9B51-4127-AEB7-AA1F0BE53BD6@dominion.thruhere.net>
On Mon, 2011-10-24 at 16:18 +0200, Koen Kooi wrote:
> Op 24 okt. 2011, om 16:10 heeft Richard Purdie het volgende geschreven:
>
> > On Mon, 2011-10-24 at 15:37 +0200, Koen Kooi wrote:
> >> Op 24 okt. 2011, om 15:34 heeft Richard Purdie het volgende geschreven:
> >>
> >>> On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> >>>> From: Khem Raj <raj.khem@gmail.com>
> >>>>
> >>>> Adjust prefix.patch and delete resolve-sysroot.patch
> >>>> since its already applied upstream
> >>>>
> >>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >>>> ---
> >>>> .../libtool/{libtool.inc => libtool-2.4.2.inc} | 26 +++++++++---
> >>>> meta/recipes-devtools/libtool/libtool-2.4.inc | 13 ------
> >>>> ...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} | 2 +-
> >>>> ...btool-native_2.4.bb => libtool-native_2.4.2.bb} | 2 +-
> >>>> ...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} | 2 +-
> >>>> meta/recipes-devtools/libtool/libtool/prefix.patch | 46 ++++++++++----------
> >>>> .../libtool/libtool/resolve-sysroot.patch | 42 ------------------
> >>>> .../libtool/{libtool_2.4.bb => libtool_2.4.2.bb} | 2 +-
> >>>> 8 files changed, 47 insertions(+), 88 deletions(-)
> >>>> rename meta/recipes-devtools/libtool/{libtool.inc => libtool-2.4.2.inc} (57%)
> >>>> delete mode 100644 meta/recipes-devtools/libtool/libtool-2.4.inc
> >>>> rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} (98%)
> >>>> rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb => libtool-native_2.4.2.bb} (96%)
> >>>> rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} (97%)
> >>>> delete mode 100644 meta/recipes-devtools/libtool/libtool/resolve-sysroot.patch
> >>>> rename meta/recipes-devtools/libtool/{libtool_2.4.bb => libtool_2.4.2.bb} (94%)
> >>>>
> >>>> diff --git a/meta/recipes-devtools/libtool/libtool.inc b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >>>> similarity index 57%
> >>>> rename from meta/recipes-devtools/libtool/libtool.inc
> >>>> rename to meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >>>> index ef9095b..1f652ef 100644
> >>>> --- a/meta/recipes-devtools/libtool/libtool.inc
> >>>> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >>>> @@ -1,4 +1,3 @@
> >>>> -SUMMARY = "Generic library support script"
> >>>
> >>> Why drop the SUMMARY field?
> >>
> >> What's the difference between SUMMARY and DESCRIPTION? And what happens if both are set?
> >
> > SUMMARY is a one line 74? character summary of the package, DESCRIPTION
> > is a multiple line stream of text containing a more verbose description.
> > What happens to the data is package backend specific, I know RPM has
> > uses for both. There was definitely discussion about this on the mailing
> > list at the time, I'm not sure what if anything made it into the manuals
> > but if its not there it should be added.
>
>
> It seems to get OR'd:
>
> meta/classes/package_deb.bbclass: summary = bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or "."
> package_deb.bbclass: description = bb.data.getVar('DESCRIPTION', localdata, True) or "."
>
> meta/classes/package_ipk.bbclass: summary = bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or "."
> package_ipk.bbclass: description = bb.data.getVar('DESCRIPTION', localdata, True) or "."
>
> meta/classes/package_rpm.bbclass: srcsummary = (bb.data.getVar('SUMMARY', d, True) or bb.data.getVar('DESCRIPTION', d, True) or ".")
> package_rpm.bbclass: srcdescription = bb.data.getVar('DESCRIPTION', d, True) or "."
So the summary is SUMMARY if set, or DESCRIPTION if set else "."
The description is DESCRIPTION if set else "."
which was done to fall back to the case where recipes just set
DESCRIPTION.
Cheers,
Richard
^ permalink raw reply
* Re: [CONSOLIDATED PULL 11/27] pulseaudio-0.9.23: inherit perlnative to work around build on host without XML/Parser.pm
From: Martin Jansa @ 2011-10-24 14:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319465707.25011.21.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
On Mon, Oct 24, 2011 at 03:15:07PM +0100, Richard Purdie wrote:
> On Mon, 2011-10-24 at 15:19 +0200, Koen Kooi wrote:
> > Op 24 okt. 2011, om 15:15 heeft Richard Purdie het volgende geschreven:
> >
> > > On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> > >> From: Martin Jansa <Martin.Jansa@gmail.com>
> > >>
> > >> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > >> ---
> > >> .../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
> > >> 1 files changed, 1 insertions(+), 1 deletions(-)
> > >>
> > >> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > >> index 33f5e15..4ac2418 100644
> > >> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > >> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > >> @@ -4,7 +4,7 @@ PR = "r5"
> > >>
> > >> DEPENDS += "gdbm speex"
> > >>
> > >> -inherit gettext
> > >> +inherit gettext perlnative
> > >
> > > This doesn't look right. If we need xmlparser, we should state that in
> > > DEPENDS. If that is added to DEPENDS, I'm not sure we still need the
> > > inherit of perlnative?
> >
> > If you need xmlparser during the build you almost always need the
> > perlnative wrapper as well :(
>
> I was under the impression that we'd fixed most of those issues :/. It
> could well be a valid dependency in this case so I'll take the patch
> with the added DEPENDS.
Those were imho transitive deps from intltool, that's why this is a bit
different.
Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024141253.GF26649@sapphire.tkos.co.il>
On 10/24/2011 04:12 PM, Baruch Siach :
> Hi Nicolas,
>
> On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>> The Evaluation Kit at91sam9m10g45ek includes it.
>> This first basic support will be populated as drivers and boards will be
>> converted to device tree.
>> Contains serial, dma and interrupt controllers.
>>
>> The generic board file still takes advantage of platform data for early serial
>> init. As we need a storage media and the NAND flash driver is not converted to
>> DT yet, we keep old initialization for it.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>
> [snip]
>
>> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
>
> Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more
> appropriate name?
For sure that makes sense. I queue this change and make it appear only
in the pull request if it is the only change requested.
>> + /* Maintainer: Atmel */
>> + .timer = &at91sam926x_timer,
>> + .map_io = at91_map_io,
>> + .init_early = ek_init_early,
>> + .init_irq = at91_dt_init_irq,
>> + .init_machine = at91_dt_device_init,
>> + .dt_compat = at91_dt_board_compat,
>> +MACHINE_END
>
> baruch
Thanks for your review,
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:32 UTC (permalink / raw)
To: Baruch Siach
Cc: devicetree-discuss, linux-kernel, grant.likely, plagnioj,
linux-arm-kernel
In-Reply-To: <20111024141253.GF26649@sapphire.tkos.co.il>
On 10/24/2011 04:12 PM, Baruch Siach :
> Hi Nicolas,
>
> On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>> The Evaluation Kit at91sam9m10g45ek includes it.
>> This first basic support will be populated as drivers and boards will be
>> converted to device tree.
>> Contains serial, dma and interrupt controllers.
>>
>> The generic board file still takes advantage of platform data for early serial
>> init. As we need a storage media and the NAND flash driver is not converted to
>> DT yet, we keep old initialization for it.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>
> [snip]
>
>> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
>
> Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more
> appropriate name?
For sure that makes sense. I queue this change and make it appear only
in the pull request if it is the only change requested.
>> + /* Maintainer: Atmel */
>> + .timer = &at91sam926x_timer,
>> + .map_io = at91_map_io,
>> + .init_early = ek_init_early,
>> + .init_irq = at91_dt_init_irq,
>> + .init_machine = at91_dt_device_init,
>> + .dt_compat = at91_dt_board_compat,
>> +MACHINE_END
>
> baruch
Thanks for your review,
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 2/2] i2c/nomadik: runtime PM support
From: Magnus Damm @ 2011-10-24 14:32 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonas Aaberg, Linus Walleij, Ben Dooks,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Rafael J. Wysocki,
Russell King - ARM Linux
In-Reply-To: <CACRpkdZmifrV3o59JrWx2Z6DAqHO80W4d=7NJ6OipAOrbazgXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Oct 21, 2011 at 8:19 PM, Linus Walleij <linus.walleij-QSEj5FYQhm5QFI55V6+gNQ@public.gmane.orgg> wrote:
> On Thu, Oct 20, 2011 at 6:44 PM, Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Oct 21, 2011 at 1:23 AM, Linus Walleij
>> <linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org> wrote:
>>> From: Jonas Aaberg <jonas.aberg-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
> ...
>>> +static int nmk_i2c_runtime_suspend(struct device *dev)
>>> +{
>>> + clk_disable(nmk_i2c->clk);
> (...)
>>> +}
>>> +
>>> +static int nmk_i2c_runtime_resume(struct device *dev)
>>> +{
> (...)
>>> + clk_enable(nmk_i2c->clk);
>>> + return 0;
>>> +}
>>> +
>>
>> Hm, on SH-Mobile ARM we never control any clocks from the driver
>> runtime pm callbacks.
>
> OK so you're using pm_clk_add_notifier() and the standard
> implementation from drivers/base/power/clock_ops.c?
We are using the standard implementation together with
pm_clk_add_notifier() to point out our platform_bus_notifier in
arch/arm/mach-shmobile/pm_runtime.c. My intention with the comment
above was not to so focused on the notifier, more that soc-specific
code can use pm_clk_add() to add multiple clocks to a certain struct
device.
>> (...) In our case the runtime suspend callbacks are only invoked
>> when all the devices in the power domain happen to have a zero runtime
>> pm use count. So if you control your clocks from those callbacks then
>> they will be mostly left on which may not be what you want.
>
> We have power domains implemented as well, but currently these
> handle power domain regulators and pin control only,
> not clocking.
>
> They are registered to the platform and amba bus using
> bus_register_notifier() rather than pm_*() notifiers though,
> but we listen to the same events
> BUS_NOTIFY_[BIND|UNBOUND]_DRIVER
I probably mentioned this earlier, but on SH-Mobile ARM drivers we
control both clocks and power domains using the same
pm_runtime_get()/put() functions. The clocks are turned off
immediately, but the power domains will only be turned off when all
included devices are idle according to Runtime PM. At this
all-devices-in-one-power-domain-are-idle time we actually invoke the
->runtime_suspend() callbacks. This is handled by generic code and can
easily be used by anyone.
> So your suggestion is to move clock control for all
> platform devices to the overarching platform code where
> we also handle the power domain regulators and pin
> control?
No, I wouldn't go that far to suggest that. =) I'm just saying that
using Runtime PM for clock and power domain control on a per-device
granularity in the driver is working well for us. Especially since we
can let the soc-code associate multiple clocks to each struct device
with pm_clk_add().
I'm soon going to hack on trying to tie in voltage control in the
soc-specific Runtime PM code. Right now the voltage is static but we
gate off various parts of the SoC. After prototyping with the voltage
control code then perhaps it would be easier for me to recommend you
something. =)
The reason why I replied to the email initially was to point out that
your way of using Runtime PM seems quite different from our way. It
looked like this driver wanted to have the ->runtime_suspend()
callback executed as soon as possible to control the clock. So if you
intend to execute the ->runtime_suspend() callbacks directly then it
may become difficult for you to use the common pm domain code base
that Rafael has been working on.
> Currently we have something similar for the AMBA
> bus here, since it actually has code in place to grab
> the block clock on probe() and its own runtime PM
> callbacks. Since the bus driver holds the actual reference
> to the clock, we have to call down into the bus callbacks
> from the platform runtime PM implementation since our
> implementation takes precedence. I guess this is expected
> way of doing it?
I'm not sure actually. We should sit down together and discuss this
over an afternoon - hopefully together with Rafael. I could probably
find time during next week in Orlando if you're around.
> I see three possible paradigms here:
>
> (A) dev_power_domain implementation in
> platform/board code handle silicon clocks and regulators.
>
> (B) Bus (as AMBA) driver handle silicon clocks and
> regulators
>
> (C) Devices handle clocks and regulators in their runtime
> PM callbacks themselves
>
> So now ARM SHmobile does (A), PrimeCell drivers do
> (B) and this patch attempted to do (C).
>
> And our way of handling AMBA is a mixture calling
> the bus callbacks from the platform like (A)+(B)
>
> I guess (A) and (C) won't mix very well since both
> handle platform devices and things will screw up if
> say our platform and SHmobile would use the same
> driver.
Exactly my point.
Thanks,
/ magnus
^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:32 UTC (permalink / raw)
To: Baruch Siach
Cc: robherring2, grant.likely, devicetree-discuss, plagnioj,
linux-kernel, linux-arm-kernel
In-Reply-To: <20111024141253.GF26649@sapphire.tkos.co.il>
On 10/24/2011 04:12 PM, Baruch Siach :
> Hi Nicolas,
>
> On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>> The Evaluation Kit at91sam9m10g45ek includes it.
>> This first basic support will be populated as drivers and boards will be
>> converted to device tree.
>> Contains serial, dma and interrupt controllers.
>>
>> The generic board file still takes advantage of platform data for early serial
>> init. As we need a storage media and the NAND flash driver is not converted to
>> DT yet, we keep old initialization for it.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>
> [snip]
>
>> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
>
> Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more
> appropriate name?
For sure that makes sense. I queue this change and make it appear only
in the pull request if it is the only change requested.
>> + /* Maintainer: Atmel */
>> + .timer = &at91sam926x_timer,
>> + .map_io = at91_map_io,
>> + .init_early = ek_init_early,
>> + .init_irq = at91_dt_init_irq,
>> + .init_machine = at91_dt_device_init,
>> + .dt_compat = at91_dt_board_compat,
>> +MACHINE_END
>
> baruch
Thanks for your review,
Best regards,
--
Nicolas Ferre
^ 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.