* Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
From: Rusty Russell @ 2009-09-29 13:11 UTC (permalink / raw)
To: Amit Shah; +Cc: virtualization, linux-kernel, alan
In-Reply-To: <1252678386-17404-2-git-send-email-amit.shah@redhat.com>
On Fri, 11 Sep 2009 11:43:06 pm Amit Shah wrote:
> Expose multiple char devices ("ports") for simple communication
> between the host userspace and guest.
OK, I think other comments have died down, so it's time for a review. This
was the latest patch I could find.
The obvious way to do this is to use multiple pairs of virtqueues. Is this
silly for some reason? Yes, we're restricted to 32k ports.
It means that if we see the MULTIQUEUE feature, we can look for the other
queues. Our current MSI-X friendly API makes that a little painful, but
if we resolve that our code should be sweetness, no?
Rusty.
^ permalink raw reply
* Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
From: Amit Shah @ 2009-09-29 13:09 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Rusty Russell, Alan Cox, virtualization, linux-kernel
In-Reply-To: <200909291456.56723.borntraeger@de.ibm.com>
On (Tue) Sep 29 2009 [14:56:56], Christian Borntraeger wrote:
> Am Dienstag 29 September 2009 14:20:06 schrieb Amit Shah:
> > Christian tested the patch on s390 and found that the output was
> > very slow. He tracked it down to put_chars never getting init'ed
> > to the final value.
> >
> > Signed-off-by: Amit Shah <amit.shah@redhat.com>
>
> Thanks. This fix is
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Great, thanks. However I was thinking of moving this init to the probe()
routine instead of in the init_conosle routine just because multiple
consoles can be added and we don't want to init this each time.. just
once in probe is fine.
> I am a bit reluctant to Ack the whole change, since my preference would have
> been to not merge virtio serial/console and instead keeping both separate.
> We have already managed to clutter all other virtio drivers with tons of
> configuration stuff and feature bits - and every driver uses a different model
> for configuration and commands (feature bits, config space, config_change
> indication, extra config virtqueue, commands embedded into the data....).
> Using a different device ID for a different use seem like a better way to me.
Well, Anthony described your objection as a comment in passing and that
you weren't strongly against merging the two drivers when I brought up
your argument sometime back.
Also, it was difficult to make progress and just keep fighting about
these issues. So even though I didn't like merging the stuff, I had to.
Rusty too in a recent mail mentioned he sees both the drivers as one
because the functionlities are similar.
> On the other hand, this patch allows more than one console (I have not tested
> this feature) and with this fix applied I dont see any obvious problems.
Note though that to use the multiple consoles, you'll have to modify
your userspace to handle the new messages that get passed between the
host and the guest (one can argue I've done the guest part; you only
have the host part to be done :-))
> For the console part I can give a
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> (console)
Thanks again. I'll put this in the next spin.
> Ignoring my preference for having a separate driver and devids, I have no
> opinion about the generic communication stuff - no ack or nack.
Amit
^ permalink raw reply
* Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
From: Amit Shah @ 2009-09-29 13:09 UTC (permalink / raw)
To: Christian Borntraeger; +Cc: virtualization, linux-kernel, Alan Cox
In-Reply-To: <200909291456.56723.borntraeger@de.ibm.com>
On (Tue) Sep 29 2009 [14:56:56], Christian Borntraeger wrote:
> Am Dienstag 29 September 2009 14:20:06 schrieb Amit Shah:
> > Christian tested the patch on s390 and found that the output was
> > very slow. He tracked it down to put_chars never getting init'ed
> > to the final value.
> >
> > Signed-off-by: Amit Shah <amit.shah@redhat.com>
>
> Thanks. This fix is
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Great, thanks. However I was thinking of moving this init to the probe()
routine instead of in the init_conosle routine just because multiple
consoles can be added and we don't want to init this each time.. just
once in probe is fine.
> I am a bit reluctant to Ack the whole change, since my preference would have
> been to not merge virtio serial/console and instead keeping both separate.
> We have already managed to clutter all other virtio drivers with tons of
> configuration stuff and feature bits - and every driver uses a different model
> for configuration and commands (feature bits, config space, config_change
> indication, extra config virtqueue, commands embedded into the data....).
> Using a different device ID for a different use seem like a better way to me.
Well, Anthony described your objection as a comment in passing and that
you weren't strongly against merging the two drivers when I brought up
your argument sometime back.
Also, it was difficult to make progress and just keep fighting about
these issues. So even though I didn't like merging the stuff, I had to.
Rusty too in a recent mail mentioned he sees both the drivers as one
because the functionlities are similar.
> On the other hand, this patch allows more than one console (I have not tested
> this feature) and with this fix applied I dont see any obvious problems.
Note though that to use the multiple consoles, you'll have to modify
your userspace to handle the new messages that get passed between the
host and the guest (one can argue I've done the guest part; you only
have the host part to be done :-))
> For the console part I can give a
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> (console)
Thanks again. I'll put this in the next spin.
> Ignoring my preference for having a separate driver and devids, I have no
> opinion about the generic communication stuff - no ack or nack.
Amit
^ permalink raw reply
* [PATCH] i2c: imx: check busy bit when START/STOP
From: Wolfram Sang @ 2009-09-29 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e090d470909290441i7016c4f4g9a929d78838f9b7@mail.gmail.com>
Hi Richard,
On Tue, Sep 29, 2009 at 07:41:44PM +0800, Richard Zhao wrote:
> After START, wait busy bit to be set and
> after STOP, wait busy bit to be clear.
>
> Disable clock when it's possible to save power.
As those are two different issues, could you make two patches out of it? Also,
I think it will make reviewing easier if you'd drop the debug print-outs.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20090929/1bb44bad/attachment.sig>
^ permalink raw reply
* Re: [PATCH] i2c: imx: check busy bit when START/STOP
From: Wolfram Sang @ 2009-09-29 13:09 UTC (permalink / raw)
To: Richard Zhao
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sascha Hauer
In-Reply-To: <4e090d470909290441i7016c4f4g9a929d78838f9b7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hi Richard,
On Tue, Sep 29, 2009 at 07:41:44PM +0800, Richard Zhao wrote:
> After START, wait busy bit to be set and
> after STOP, wait busy bit to be clear.
>
> Disable clock when it's possible to save power.
As those are two different issues, could you make two patches out of it? Also,
I think it will make reviewing easier if you'd drop the debug print-outs.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] direct I/O fallback sync simplification
From: Jan Kara @ 2009-09-29 13:08 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Al Viro, Nick Piggin, Jan Kara, linux-fsdevel
In-Reply-To: <20090923130730.GC10759@lst.de>
On Wed 23-09-09 15:07:30, Christoph Hellwig wrote:
> In the case of direct I/O falling back to buffered I/O we sync data
> twice currently: once at the end of generic_file_buffered_write using
> filemap_write_and_wait_range and once a little later in
> __generic_file_aio_write using do_sync_mapping_range with all flags set.
>
> The wait before write of the do_sync_mapping_range call does not make
> any sense, so just keep the filemap_write_and_wait_range call and move
> it to the right spot.
>
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks much better. Acked-by: Jan Kara <jack@suse.cz>
Honza
>
> Index: vfs-2.6.git/mm/filemap.c
> ===================================================================
> --- vfs-2.6.git.orig/mm/filemap.c 2009-09-22 14:20:59.917761567 -0300
> +++ vfs-2.6.git/mm/filemap.c 2009-09-22 14:28:01.833832530 -0300
> @@ -2265,15 +2265,6 @@ generic_file_buffered_write(struct kiocb
> *ppos = pos + status;
> }
>
> - /*
> - * If we get here for O_DIRECT writes then we must have fallen through
> - * to buffered writes (block instantiation inside i_size). So we sync
> - * the file data here, to try to honour O_DIRECT expectations.
> - */
> - if (unlikely(file->f_flags & O_DIRECT) && written)
> - status = filemap_write_and_wait_range(mapping,
> - pos, pos + written - 1);
> -
> return written ? written : status;
> }
> EXPORT_SYMBOL(generic_file_buffered_write);
> @@ -2372,10 +2363,7 @@ ssize_t __generic_file_aio_write(struct
> * semantics.
> */
> endbyte = pos + written_buffered - written - 1;
> - err = do_sync_mapping_range(file->f_mapping, pos, endbyte,
> - SYNC_FILE_RANGE_WAIT_BEFORE|
> - SYNC_FILE_RANGE_WRITE|
> - SYNC_FILE_RANGE_WAIT_AFTER);
> + err = filemap_write_and_wait_range(file->f_mapping, pos, endbyte);
> if (err == 0) {
> written = written_buffered;
> invalidate_mapping_pages(mapping,
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
* [U-Boot] RFC USB composite devices
From: Tom @ 2009-09-29 13:07 UTC (permalink / raw)
To: u-boot
In-Reply-To: <3efb10970909290130wb2dd0c3rc8d09d9bcbf036af@mail.gmail.com>
Remy Bohmer wrote:
> Hi Tom,
>
> 2009/9/28 Tom <Tom.Rix@windriver.com>:
>> Soon you will see a v2 of my OMAP3 USB device support.
>> After which I will be working on adding a 'fastboot' device.
>> Ref :
>> https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=FAQ-8%3A+Zoom-II+Android%C2%A0fastboot
>>
>> I would like to add this as composite device with the other device being
>> usbtty.
>>
>> The usb device and composite device support seems to be entirely based on
>> usbtty.Is there a newer interface that needs some help bringing to the
>> mainline? Else, ideas on how to do this cleanly ?
>
> Well, I have the complete Linux gadget layer as USB device layer in
> U-boot. Maybe this helps. I have not found the time yet to push it
> forward...
> It can be found in the u-boot-usb branch.
> (http://git.denx.de/?p=u-boot/u-boot-usb.git;a=shortlog;h=refs/heads/cdc)
>
> Remy
Thanks!
I have taken a look at this.
It looks like the reference is an ethernet over usb device on at91.
I have an at91sam9g20-ek. Is this compatibly with your work?
Else I will just jump in with omap.
Are there any missing pieces that I should be aware of?
Tom
^ permalink raw reply
* Re: [PATCH 2.6.31-rc9] net: VMware virtual Ethernet NIC driver: vmxnet3
From: Arnd Bergmann @ 2009-09-29 13:05 UTC (permalink / raw)
To: Chris Wright
Cc: Shreyas Bhatewara, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Stephen Hemminger, David S. Miller,
Jeff Garzik, Anthony Liguori, Greg Kroah-Hartman, Andrew Morton,
virtualization, pv-drivers@vmware.com
In-Reply-To: <20090929085333.GC3958@sequoia.sous-sol.org>
On Tuesday 29 September 2009, Chris Wright wrote:
> > +struct Vmxnet3_MiscConf {
> > + struct Vmxnet3_DriverInfo driverInfo;
> > + uint64_t uptFeatures;
> > + uint64_t ddPA; /* driver data PA */
> > + uint64_t queueDescPA; /* queue descriptor table PA */
> > + uint32_t ddLen; /* driver data len */
> > + uint32_t queueDescLen; /* queue desc. table len in bytes */
> > + uint32_t mtu;
> > + uint16_t maxNumRxSG;
> > + uint8_t numTxQueues;
> > + uint8_t numRxQueues;
> > + uint32_t reserved[4];
> > +};
>
> should this be packed (or others that are shared w/ device)? i assume
> you've already done 32 vs 64 here
I would not mark it packed, because it already is well-defined on all
systems. You should add __packed only to the fields where you screwed
up, but not to structures that already work fine.
One thing that should possibly be fixed is the naming of identifiers, e.g.
's/Vmxnet3_MiscConf/vmxnet3_misc_conf/g', unless these header files are
shared with the host implementation.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2.6.31-rc9] net: VMware virtual Ethernet NIC driver: vmxnet3
From: Arnd Bergmann @ 2009-09-29 13:05 UTC (permalink / raw)
To: Chris Wright
Cc: pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, virtualization, Greg Kroah-Hartman,
Anthony Liguori, Jeff Garzik, Andrew Morton, Stephen Hemminger,
David S. Miller
In-Reply-To: <20090929085333.GC3958@sequoia.sous-sol.org>
On Tuesday 29 September 2009, Chris Wright wrote:
> > +struct Vmxnet3_MiscConf {
> > + struct Vmxnet3_DriverInfo driverInfo;
> > + uint64_t uptFeatures;
> > + uint64_t ddPA; /* driver data PA */
> > + uint64_t queueDescPA; /* queue descriptor table PA */
> > + uint32_t ddLen; /* driver data len */
> > + uint32_t queueDescLen; /* queue desc. table len in bytes */
> > + uint32_t mtu;
> > + uint16_t maxNumRxSG;
> > + uint8_t numTxQueues;
> > + uint8_t numRxQueues;
> > + uint32_t reserved[4];
> > +};
>
> should this be packed (or others that are shared w/ device)? i assume
> you've already done 32 vs 64 here
I would not mark it packed, because it already is well-defined on all
systems. You should add __packed only to the fields where you screwed
up, but not to structures that already work fine.
One thing that should possibly be fixed is the naming of identifiers, e.g.
's/Vmxnet3_MiscConf/vmxnet3_misc_conf/g', unless these header files are
shared with the host implementation.
Arnd <><
^ permalink raw reply
* Re: [PATCH 00/80] Kernel based checkpoint/restart [v18]
From: Daniel Lezcano @ 2009-09-29 13:29 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Andrew Morton, linux-api, containers, linux-kernel, linux-mm,
mingo, torvalds, xemul
In-Reply-To: <20090928163704.GA3327@us.ibm.com>
Serge E. Hallyn wrote:
> Quoting Andrew Morton (akpm@linux-foundation.org):
>
>> On Wed, 23 Sep 2009 19:50:40 -0400
>> Oren Laadan <orenl@librato.com> wrote:
>>
>>> Q: What about namespaces ?
>>> A: Currrently, UTS and IPC namespaces are restored. They demonstrate
>>> how namespaces are handled. More to come.
>>>
>> Will this new code muck up the kernel?
>>
[ cut ]
> For network namespaces i think it's clearer that a wrapper
> program should set up the network for the restarted init task,
> while the usrspace code should recreate any private network
> namespaces and veth's which were created by the application.
> But it still needs discussion.
>
Ok for the restart, but for the checkpoint, how do you access the
network setup from a process which belongs to another namespace context ?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] Drop Posix Capabilities
From: Steve Grubb @ 2009-09-29 13:00 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1254181253.2659.27.camel@localhost.localdomain>
On Monday 28 September 2009 07:40:53 pm Marcel Holtmann wrote:
> I quickly looked over the pc.in file and it looks good to me.
Thanks.
> Thanks foradding this. Another question that comes to my mind. Where do you
> have the GIT tree for libcap-ng so we can track the development?
I've never needed to use git - so no git tree. The project has a home page
here: http://people.redhat.com/sgrubb/libcap-ng/
and I announce package updates at freshmeat.net. The libcap-ng package is
stable and I would not have made a release yesterday if it weren't for needing
to a pc file. I don't forsee much development in libcap-ng unless there are
updates in the kernel that I need to take into account. IOW, all planned
features are complete and I'm not tracking any bugs.
> > > I like to have capability dropping in bluetoothd, but I do wanna do it
> > > with a proper upstream project.
> >
> > one other thing I thought I would point out. The patch I sent can make it
> > easy to run the bluetooth daemon as non-root user. If we switch this
> > line:
> > capng_apply(CAPNG_SELECT_BOTH);
> >
> > to
> >
> > capng_change_id(uid, gid, CAPNG_DROP_SUPP_GRP | CAPNG_CLEAR_BOUNDING);
> >
> > then the job is easier. Of course you would likely need to fixup file
> > permissions in places, but in theory a non-root bluetooth daemon is
> > possible with a 1 line change in the patch. You would probably want to
> > add error handling and a way to specify the uid/gid, too.
>
> I am not really sold on the non-root daemon idea and there might be
> hidden problems where this will not work out. However I don't mind
> trying at some point, but there are other things to sort out first. We
> should postpone this for the 5.x series.
Sure, I just wanted to point out that its a 1 line change in code if you ever
wanted to do this.
> Please re-send the original patch using pkg-config so I can go ahead an
> apply it. Even if Rawhide is not carrying the updated libcap-ng package.
OK, as soon as I figure out pkg-config. M4 is easier. :)
-Steve
^ permalink raw reply
* migrate_set_downtime bug
From: Dietmar Maurer @ 2009-09-29 13:00 UTC (permalink / raw)
To: kvm
using 0.11.0, live migration works as expected, but max downtime does not seem to work, for example:
# migrate_set_downtime 1
After that tcp migration has much longer downtimes (up to 20 seconds).
Also, it seems that the 'monitor' is locked (take up to 10 seconds until I get a monitor prompt).
Someone else get this behavior?
- Dietmar
^ permalink raw reply
* [DRBD-announce] drbd-8.3.3rc3.tar.gz
From: Philipp Reisner @ 2009-09-29 13:00 UTC (permalink / raw)
To: drbd-announce; +Cc: drbd-user
Hi,
We are still holding our breath how and when DRBD will land in
Linux mainline. I was told, that it can go in after 2.6.32-rc1
since it is a driver and not a patch to the more central parts
of the kernel. It will go in through Jens Axboe, although I
do not know when exactly.
To relieve the strain a bit, here is an other rc of DRBD-8.3.3
The main difference to rc2 is that the default values of
sndbuf-size rcvbuf-size where changed to 0 (auto tune).
They have been 128k before.
This take the burden to get the socket send buffer tunes
right off the administrator, but make sure that TCP's sysctls
settings are sane. I.e.
net.core.rmem_max = 10485760 (byte per socket)
net.core.wmem_max = 10485760 (byte per socket)
net.ipv4.tcp_rmem = 65536 87380 10485760 (min/def/max byte per socket)
net.ipv4.tcp_wmem = 65536 65536 10485760 (min/def/max byte per socket)
net.ipv4.tcp_mem = 128000 170666 256000 (min/pressure/max pages in total)
8.3.3rc3 (api:86/proto:86-91)
--------
* Correctly deal with large bitmaps (Bugz 239, 240)
* Fixed a segfault in drbdadm's parser for unknown sync-after dependencies
* DRBD_PEER was not set for handlers (introduced in 8.3.2) (Bugz 241)
* Fixed a bug that could cause reads off diskless DRBD devices to get very slow
* Fixed a deadlock possible when IO errors occure during resync (Bugz 224)
* Do not do a full sync in case P_SYNC_UUID packet gets lost (Bugz 244)
* Do not forget a resync in case the last ACK of a resync gets lost
* The UUID compare function now handles more cases when connection/disk got
lost during UUID updates (Bugz 251, 254)
* If a resource gets renamed (only) update its /dev/
* drbdsetup get-gi/show-gi sometimes warned about unknown tags (Bugz 253)
* Autotune sndbuf-size and rcvbuf-size by default
* Fixed many spelling errors
* Improvements on the crm-fence-peer Pacemaker integration
* Do not upgrade a Consistent disk to UpToDate when the fence-peer handler
can not reach the peer (Bugz 198)
* Support for Infiniband via SDP (sockets direct protocol)
* Install bash completion stuff on SLES11
* Following Linux upstream changes 2.6.31
http://git.drbd.org/?p=drbd-8.3.git;a=tag;h=drbd-8.3.3rc3
http://oss.linbit.com/drbd/8.3/drbd-8.3.3rc3.tar.gz
--
: Dipl-Ing Philipp Reisner
: LINBIT | Your Way to High Availability
: Tel: +43-1-8178292-50, Fax: +43-1-8178292-82
: http://www.linbit.com
DRBD(R) and LINBIT(R) are registered trademarks of LINBIT, Austria.
^ permalink raw reply
* Re: ASoC: SND_SOC_DAPM_LINE behavior
From: Peter Ujfalusi @ 2009-09-29 12:59 UTC (permalink / raw)
To: ext Mark Brown; +Cc: alsa-devel@alsa-project.org
In-Reply-To: <20090929124439.GA8632@rakim.wolfsonmicro.main>
On Tuesday 29 September 2009 15:44:40 ext Mark Brown wrote:
> On Tue, Sep 29, 2009 at 03:36:39PM +0300, Peter Ujfalusi wrote:
> > The DAPM routing is something like this in the codec driver:
> > |DAC|------------->| |
> > |
> > |Playback Mixer|->|OUTPUT|
> > |
> > |INPUT|->|Bypass|->| |
> > |
> > |SWITCH|
> >
> > Now if in the machine driver I create the following DAPM widget:
> > SND_SOC_DAPM_LINE("Line In", NULL),
> >
> > and than connect this DAPM_LINE to the codec's INPUT (LINE-IN):
> > {"LINE-IN", NULL, "Line In"},
> >
> > Than the codec bias level would be always in ON state, regardless of the
> > state of the Bypass Switch (it is off by default).
>
> That shouldn't happen, turning off the bypass switch should break the
> path and let the bias sit at standby. I'd need to check the code but I
> expect that the fact that LINE can be either an input or an output is
> confusing things and we need to split it into two widgets, one for input
> and one for output.
It seams that the LINE itself confusing DAPM, since if I connect a LINE to the
OUTPUT that will also keep the codec bias ON all the time.
Most probably separating the LINE to LINEIN and LINEOUT in dapm would solve the
problem. This needs however change in the existing machine drivers as well, but
it should not be too big of a problem.
> The easiest thing for an actual system would just be to not bother with
> the external widget if you're not doing anything with it. It'll only
> make things work better, there's no need for the external widgets unless
> you're switching them.
Yes, that is true.
Thanks,
Péter
^ permalink raw reply
* Re: [PATCHv2 0/4] scsi: export and clean up headers
From: Michael S. Tsirkin @ 2009-09-29 12:56 UTC (permalink / raw)
To: Christoph Hellwig
Cc: James Bottomley, linux-scsi, linux-kernel, Boaz Harrosh,
Sam Ravnborg, Ulrich Drepper
In-Reply-To: <20090929124347.GA11375@infradead.org>
On Tue, Sep 29, 2009 at 08:43:47AM -0400, Christoph Hellwig wrote:
> On Tue, Sep 29, 2009 at 12:33:53PM +0200, Michael S. Tsirkin wrote:
> > This implements a minor cleanup of exported scsi headers,
> > and adds export of headers that are de-facto used by userspace.
> > The patches are on top of 2.6.32-rc1.
> > Can these be queued for 2.6.32?
> > Thanks.
>
> Before we do anything in this area we need to find an agreement who
> owns /usr/include/scsi/ .
Let's cleanup headers that we already export (that's patches 1/2 in the
series). I don't see a reason to delay that, do you?
> Right now that's glibc, and if we want to
> change it to the kernel headers we need to find a transition agreement
> with the glibc maintainer (aka mostly Uli).
Who cares? If glibc wants to carry its own headers, let it. It will
likely switch if what kernel provides is sane (it is currently not). So
let's start with cleaning up what we already have. If glibc decides not
to use it, no harm's done.
> And even then it's quite questionable if the kernel should provide
> scsi.h as it's mostly protocol defintions, not actually a kernel
> interface.
It has a ton of ioctl definitions there.
--
MST
^ permalink raw reply
* Re: Possible small bug in xfsprogs-dev/db/metadump.c
From: Christoph Hellwig @ 2009-09-29 13:00 UTC (permalink / raw)
To: Richard Sharpe; +Cc: Christoph Hellwig, xfs
In-Reply-To: <46b8a8850909281036j1bdbf61h18b4134912735d92@mail.gmail.com>
On Mon, Sep 28, 2009 at 10:36:13AM -0700, Richard Sharpe wrote:
> >
> > ? ? ? ?if (level == 0)
> > ? ? ? ? ? ? ? ?return 1;
> >
> > which should take care of the leaf nodes by exiting early.
>
> Well, yes there is, but that is the problem I encountered. It is level
> as passed in when starting at the top of the tree, which is obtained
> from the levels value in the AGF, and is decremented by one on each
> recursion:
>
> if (!(*func)(iocur_top->data, agno, agbno, level - 1, btype, arg))
>
> However, what should really be looked at is the value bb_level in the
> header in each free-space Btree node.
I think bother are equally valid. The one passed in fro mthe top should
always be right while the ondisk one might be corrupted.
> After I made that change to my changes, I started being able to
> properly count all leaf nodes and free extents, and the numbers came
> out where I expected them to be (instead of not seeing many leaf nodes
> and vastly undercounting free extents).
Still not quite understanding your problem here. Do you have a tool
of your own that doesn't start from the btree root but only walks
subtrees? In that case you need to look at the on-disk level unless
you can find out easily what level you start at. But I don't think we
need this for the existing tools that always walk from the root.
>
>
>
>
>
> --
> Regards,
> Richard Sharpe
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
---end quoted text---
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [lm-sensors] sensors.conf manpage name
From: Jean Delvare @ 2009-09-29 12:57 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4AC1C369.8090901@redhat.com>
Hi Hans,
On Tue, 29 Sep 2009 10:20:57 +0200, Hans de Goede wrote:
> I just received this bug report:
> https://bugzilla.redhat.com/show_bug.cgi?idR6178
>
> Which makes sense, so now I was thinking how to best handle this. We
> can make a sensors3.conf.5 symlink to sensors.conf.5 or we can just
> rename it. There is something to be said for both cases.
>
> sensors3.conf is the new default name, but sensors.conf is still used
> as a fallback by libsensors.
>
> So what is your 2 cents on this ?
I believe a symlink would solve the problem better. If we rename the
man page, then I can see old-timers complain next time they try "man
sensors.conf" and it fails. And as you said, both names are equally
valid.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* [PATCH] net: restore tx timestamping for accelerated vlans
From: Eric Dumazet @ 2009-09-29 12:57 UTC (permalink / raw)
To: David S. Miller, Patrick McHardy; +Cc: Linux Netdev List
Since commit 9b22ea560957de1484e6b3e8538f7eef202e3596
( net: fix packet socket delivery in rx irq handler )
We lost rx timestamping of packets received on accelerated vlans.
Effect is that tcpdump on real dev can show strange timings, since it gets rx timestamps
too late (ie at skb dequeueing time, not at skb queueing time)
14:47:26.986871 IP 192.168.20.110 > 192.168.20.141: icmp 64: echo request seq 1
14:47:26.986786 IP 192.168.20.141 > 192.168.20.110: icmp 64: echo reply seq 1
14:47:27.986888 IP 192.168.20.110 > 192.168.20.141: icmp 64: echo request seq 2
14:47:27.986781 IP 192.168.20.141 > 192.168.20.110: icmp 64: echo reply seq 2
14:47:28.986896 IP 192.168.20.110 > 192.168.20.141: icmp 64: echo request seq 3
14:47:28.986780 IP 192.168.20.141 > 192.168.20.110: icmp 64: echo reply seq 3
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/dev.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 560c8c9..b8f74cf 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2288,6 +2288,9 @@ int netif_receive_skb(struct sk_buff *skb)
int ret = NET_RX_DROP;
__be16 type;
+ if (!skb->tstamp.tv64)
+ net_timestamp(skb);
+
if (skb->vlan_tci && vlan_hwaccel_do_receive(skb))
return NET_RX_SUCCESS;
@@ -2295,9 +2298,6 @@ int netif_receive_skb(struct sk_buff *skb)
if (netpoll_receive_skb(skb))
return NET_RX_DROP;
- if (!skb->tstamp.tv64)
- net_timestamp(skb);
-
if (!skb->iif)
skb->iif = skb->dev->ifindex;
^ permalink raw reply related
* Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
From: Christian Borntraeger @ 2009-09-29 12:56 UTC (permalink / raw)
To: Amit Shah; +Cc: Rusty Russell, Alan Cox, virtualization, linux-kernel
In-Reply-To: <20090929122006.GB3766@amit-x200.redhat.com>
Am Dienstag 29 September 2009 14:20:06 schrieb Amit Shah:
> Christian tested the patch on s390 and found that the output was
> very slow. He tracked it down to put_chars never getting init'ed
> to the final value.
>
> Signed-off-by: Amit Shah <amit.shah@redhat.com>
Thanks. This fix is
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
I am a bit reluctant to Ack the whole change, since my preference would have
been to not merge virtio serial/console and instead keeping both separate.
We have already managed to clutter all other virtio drivers with tons of
configuration stuff and feature bits - and every driver uses a different model
for configuration and commands (feature bits, config space, config_change
indication, extra config virtqueue, commands embedded into the data....).
Using a different device ID for a different use seem like a better way to me.
On the other hand, this patch allows more than one console (I have not tested
this feature) and with this fix applied I dont see any obvious problems.
For the console part I can give a
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> (console)
Ignoring my preference for having a separate driver and devids, I have no
opinion about the generic communication stuff - no ack or nack.
> ---
> drivers/char/virtio_console.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> index 37513e8..598bc0d 100644
> --- a/drivers/char/virtio_console.c
> +++ b/drivers/char/virtio_console.c
> @@ -571,6 +571,14 @@ int init_port_console(struct virtio_console_port
> *port) * The Host's telling us this port is a console port. Hook it
> * up with an hvc console.
> *
> + * We had set the virtio_cons put_chars implementation to
> + * put_chars for early_init. Now that we're done with the
> + * early init phase, replace it with our cons_put_chars
> + * implementation.
> + */
> + virtio_cons.put_chars = cons_put_chars;
> +
> + /*
> * To set up and manage our virtual console, we call
> * hvc_alloc().
> *
^ permalink raw reply
* Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
From: Christian Borntraeger @ 2009-09-29 12:56 UTC (permalink / raw)
To: Amit Shah; +Cc: virtualization, linux-kernel, Alan Cox
In-Reply-To: <20090929122006.GB3766@amit-x200.redhat.com>
Am Dienstag 29 September 2009 14:20:06 schrieb Amit Shah:
> Christian tested the patch on s390 and found that the output was
> very slow. He tracked it down to put_chars never getting init'ed
> to the final value.
>
> Signed-off-by: Amit Shah <amit.shah@redhat.com>
Thanks. This fix is
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
I am a bit reluctant to Ack the whole change, since my preference would have
been to not merge virtio serial/console and instead keeping both separate.
We have already managed to clutter all other virtio drivers with tons of
configuration stuff and feature bits - and every driver uses a different model
for configuration and commands (feature bits, config space, config_change
indication, extra config virtqueue, commands embedded into the data....).
Using a different device ID for a different use seem like a better way to me.
On the other hand, this patch allows more than one console (I have not tested
this feature) and with this fix applied I dont see any obvious problems.
For the console part I can give a
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> (console)
Ignoring my preference for having a separate driver and devids, I have no
opinion about the generic communication stuff - no ack or nack.
> ---
> drivers/char/virtio_console.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> index 37513e8..598bc0d 100644
> --- a/drivers/char/virtio_console.c
> +++ b/drivers/char/virtio_console.c
> @@ -571,6 +571,14 @@ int init_port_console(struct virtio_console_port
> *port) * The Host's telling us this port is a console port. Hook it
> * up with an hvc console.
> *
> + * We had set the virtio_cons put_chars implementation to
> + * put_chars for early_init. Now that we're done with the
> + * early init phase, replace it with our cons_put_chars
> + * implementation.
> + */
> + virtio_cons.put_chars = cons_put_chars;
> +
> + /*
> * To set up and manage our virtual console, we call
> * hvc_alloc().
> *
^ permalink raw reply
* Re: 2.6.31 xfs_fs_destroy_inode: cannot reclaim
From: Christoph Hellwig @ 2009-09-29 12:57 UTC (permalink / raw)
To: Patrick Schreurs; +Cc: Christoph Hellwig, Tommy van Leeuwen, xfs
In-Reply-To: <4AC1DE4E.6060102@news-service.com>
On Tue, Sep 29, 2009 at 12:15:42PM +0200, Patrick Schreurs wrote:
> Update: We've applied this patch on 2 servers. They didn't crash until
> now. Today we've applied the patch on 6 other servers.
Thanks. I'll prepare a patch for upstream as the patch is extremly
useful by itself. IF other issues show up I'll fix it on top of it.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* TMIO MMC: full patchset.
From: Ian Molton @ 2009-09-29 12:52 UTC (permalink / raw)
To: linux-mmc, magnus.damm, sameo, pb, philipp.zabel
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
Hi guys,
This is the full TMIO MMC patchset, compiled, tested, checkpatch passed.
Please base all tmio based code on top of this patchset.
Also, please can I get some review on the 'slow init' patch in this
set as it modifies the mmc core. It should be harmless for all
non-broken hardware.
--
Ian Molton
Linux, Automotive, and other hacking:
http://www.mnementh.co.uk/
[-- Attachment #2: 0001-MMC-hardware-abstraction-for-CNF-area.patch --]
[-- Type: text/x-patch, Size: 22040 bytes --]
From 46909530b67a1c83c1e22ac5fcfcada27d4fab54 Mon Sep 17 00:00:00 2001
From: Ian Molton <ian@mnementh.co.uk>
Date: Thu, 24 Sep 2009 23:24:18 +0100
Subject: [PATCH 1/5] MMC: hardware abstraction for CNF area
This patch abstracts out the CNF area code from tmio_mmc which is
not present in all hardware that can use this driver. This is required so that
we can suppot non-toshiba based hardware.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
---
drivers/mfd/Makefile | 6 +-
drivers/mfd/t7l66xb.c | 31 +++++++++++--
drivers/mfd/tc6387xb.c | 97 ++++++++++++++++++++++++++++++++++--------
drivers/mfd/tc6393xb.c | 56 +++++++++++++++++++++----
drivers/mfd/tmio_core.c | 54 ++++++++++++++++++++++++
drivers/mmc/host/tmio_mmc.c | 63 +++++++++------------------
drivers/mmc/host/tmio_mmc.h | 46 +++------------------
include/linux/mfd/tmio.h | 33 +++++++++++++++
8 files changed, 268 insertions(+), 118 deletions(-)
create mode 100644 drivers/mfd/tmio_core.c
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 6f8a9a1..9be344a 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -10,9 +10,9 @@ obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o
obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
-obj-$(CONFIG_MFD_T7L66XB) += t7l66xb.o
-obj-$(CONFIG_MFD_TC6387XB) += tc6387xb.o
-obj-$(CONFIG_MFD_TC6393XB) += tc6393xb.o
+obj-$(CONFIG_MFD_T7L66XB) += t7l66xb.o tmio_core.o
+obj-$(CONFIG_MFD_TC6387XB) += tc6387xb.o tmio_core.o
+obj-$(CONFIG_MFD_TC6393XB) += tc6393xb.o tmio_core.o
obj-$(CONFIG_MFD_WM8400) += wm8400-core.o
wm8350-objs := wm8350-core.o wm8350-regmap.o wm8350-gpio.o
diff --git a/drivers/mfd/t7l66xb.c b/drivers/mfd/t7l66xb.c
index 0a255c1..2fa0703 100644
--- a/drivers/mfd/t7l66xb.c
+++ b/drivers/mfd/t7l66xb.c
@@ -38,6 +38,8 @@ enum {
T7L66XB_CELL_MMC,
};
+static const struct resource t7l66xb_mmc_resources[];
+
#define SCR_REVID 0x08 /* b Revision ID */
#define SCR_IMR 0x42 /* b Interrupt Mask */
#define SCR_DEV_CTL 0xe0 /* b Device control */
@@ -83,6 +85,9 @@ static int t7l66xb_mmc_enable(struct platform_device *mmc)
spin_unlock_irqrestore(&t7l66xb->lock, flags);
+ tmio_core_mmc_enable(t7l66xb->scr + 0x200,
+ t7l66xb_mmc_resources[0].start & 0xfffe);
+
return 0;
}
@@ -106,10 +111,28 @@ static int t7l66xb_mmc_disable(struct platform_device *mmc)
return 0;
}
+static void t7l66xb_mmc_pwr(struct platform_device *mmc, int state)
+{
+ struct platform_device *dev = to_platform_device(mmc->dev.parent);
+ struct t7l66xb *t7l66xb = platform_get_drvdata(dev);
+
+ tmio_core_mmc_pwr(t7l66xb->scr + 0x200, state);
+}
+
+static void t7l66xb_mmc_clk_div(struct platform_device *mmc, int state)
+{
+ struct platform_device *dev = to_platform_device(mmc->dev.parent);
+ struct t7l66xb *t7l66xb = platform_get_drvdata(dev);
+
+ tmio_core_mmc_clk_div(t7l66xb->scr + 0x200, state);
+}
+
/*--------------------------------------------------------------------------*/
static struct tmio_mmc_data t7166xb_mmc_data = {
.hclk = 24000000,
+ .set_pwr = t7l66xb_mmc_pwr,
+ .set_no_clk_div = t7l66xb_mmc_clk_div,
};
static const struct resource t7l66xb_mmc_resources[] = {
@@ -119,11 +142,6 @@ static const struct resource t7l66xb_mmc_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = 0x200,
- .end = 0x2ff,
- .flags = IORESOURCE_MEM,
- },
- {
.start = IRQ_T7L66XB_MMC,
.end = IRQ_T7L66XB_MMC,
.flags = IORESOURCE_IRQ,
@@ -282,6 +300,9 @@ static int t7l66xb_resume(struct platform_device *dev)
if (pdata && pdata->resume)
pdata->resume(dev);
+ tmio_core_mmc_enable(t7l66xb->scr + 0x200,
+ t7l66xb_mmc_resources[0].start & 0xfffe);
+
return 0;
}
#else
diff --git a/drivers/mfd/tc6387xb.c b/drivers/mfd/tc6387xb.c
index 3280ab3..fa8da02 100644
--- a/drivers/mfd/tc6387xb.c
+++ b/drivers/mfd/tc6387xb.c
@@ -22,28 +22,41 @@ enum {
TC6387XB_CELL_MMC,
};
+struct tc6387xb {
+ void __iomem *scr;
+ struct clk *clk32k;
+ struct resource rscr;
+};
+
+static struct resource tc6387xb_mmc_resources[];
+
+/*--------------------------------------------------------------------------*/
+
#ifdef CONFIG_PM
static int tc6387xb_suspend(struct platform_device *dev, pm_message_t state)
{
- struct clk *clk32k = platform_get_drvdata(dev);
+ struct tc6387xb *tc6387xb = platform_get_drvdata(dev);
struct tc6387xb_platform_data *pdata = dev->dev.platform_data;
if (pdata && pdata->suspend)
pdata->suspend(dev);
- clk_disable(clk32k);
+ clk_disable(tc6387xb->clk32k);
return 0;
}
static int tc6387xb_resume(struct platform_device *dev)
{
- struct clk *clk32k = platform_get_drvdata(dev);
+ struct tc6387xb *tc6387xb = platform_get_drvdata(dev);
struct tc6387xb_platform_data *pdata = dev->dev.platform_data;
- clk_enable(clk32k);
+ clk_enable(tc6387xb->clk32k);
if (pdata && pdata->resume)
pdata->resume(dev);
+ tmio_core_mmc_resume(tc6387xb->scr + 0x200,
+ tc6387xb_mmc_resources[0].start & 0xfffe);
+
return 0;
}
#else
@@ -53,12 +66,32 @@ static int tc6387xb_resume(struct platform_device *dev)
/*--------------------------------------------------------------------------*/
+static void tc6387xb_mmc_pwr(struct platform_device *mmc, int state)
+{
+ struct platform_device *dev = to_platform_device(mmc->dev.parent);
+ struct tc6387xb *tc6387xb = platform_get_drvdata(dev);
+
+ tmio_core_mmc_pwr(tc6387xb->scr + 0x200, state);
+}
+
+static void tc6387xb_mmc_clk_div(struct platform_device *mmc, int state)
+{
+ struct platform_device *dev = to_platform_device(mmc->dev.parent);
+ struct tc6387xb *tc6387xb = platform_get_drvdata(dev);
+
+ tmio_core_mmc_clk_div(tc6387xb->scr + 0x200, state);
+}
+
+
static int tc6387xb_mmc_enable(struct platform_device *mmc)
{
struct platform_device *dev = to_platform_device(mmc->dev.parent);
- struct clk *clk32k = platform_get_drvdata(dev);
+ struct tc6387xb *tc6387xb = platform_get_drvdata(dev);
- clk_enable(clk32k);
+ clk_enable(tc6387xb->clk32k);
+
+ tmio_core_mmc_enable(tc6387xb->scr + 0x200,
+ tc6387xb_mmc_resources[0].start & 0xfffe);
return 0;
}
@@ -66,19 +99,21 @@ static int tc6387xb_mmc_enable(struct platform_device *mmc)
static int tc6387xb_mmc_disable(struct platform_device *mmc)
{
struct platform_device *dev = to_platform_device(mmc->dev.parent);
- struct clk *clk32k = platform_get_drvdata(dev);
+ struct tc6387xb *tc6387xb = platform_get_drvdata(dev);
- clk_disable(clk32k);
+ clk_disable(tc6387xb->clk32k);
return 0;
}
-/*--------------------------------------------------------------------------*/
-
static struct tmio_mmc_data tc6387xb_mmc_data = {
.hclk = 24000000,
+ .set_pwr = tc6387xb_mmc_pwr,
+ .set_no_clk_div = tc6387xb_mmc_clk_div,
};
+/*--------------------------------------------------------------------------*/
+
static struct resource tc6387xb_mmc_resources[] = {
{
.start = 0x800,
@@ -86,11 +121,6 @@ static struct resource tc6387xb_mmc_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = 0x200,
- .end = 0x2ff,
- .flags = IORESOURCE_MEM,
- },
- {
.start = 0,
.end = 0,
.flags = IORESOURCE_IRQ,
@@ -111,8 +141,9 @@ static struct mfd_cell tc6387xb_cells[] = {
static int tc6387xb_probe(struct platform_device *dev)
{
struct tc6387xb_platform_data *pdata = dev->dev.platform_data;
- struct resource *iomem;
+ struct resource *iomem, *rscr;
struct clk *clk32k;
+ struct tc6387xb *tc6387xb;
int irq, ret;
iomem = platform_get_resource(dev, IORESOURCE_MEM, 0);
@@ -120,18 +151,40 @@ static int tc6387xb_probe(struct platform_device *dev)
return -EINVAL;
}
+ tc6387xb = kzalloc(sizeof *tc6387xb, GFP_KERNEL);
+ if (!tc6387xb)
+ return -ENOMEM;
+
ret = platform_get_irq(dev, 0);
if (ret >= 0)
irq = ret;
else
- goto err_resource;
+ goto err_no_irq;
clk32k = clk_get(&dev->dev, "CLK_CK32K");
if (IS_ERR(clk32k)) {
ret = PTR_ERR(clk32k);
+ goto err_no_clk;
+ }
+
+ rscr = &tc6387xb->rscr;
+ rscr->name = "tc6387xb-core";
+ rscr->start = iomem->start;
+ rscr->end = iomem->start + 0xff;
+ rscr->flags = IORESOURCE_MEM;
+
+ ret = request_resource(iomem, rscr);
+ if (ret)
goto err_resource;
+
+ tc6387xb->scr = ioremap(rscr->start, rscr->end - rscr->start + 1);
+ if (!tc6387xb->scr) {
+ ret = -ENOMEM;
+ goto err_ioremap;
}
- platform_set_drvdata(dev, clk32k);
+
+ tc6387xb->clk32k = clk32k;
+ platform_set_drvdata(dev, tc6387xb);
if (pdata && pdata->enable)
pdata->enable(dev);
@@ -149,8 +202,13 @@ static int tc6387xb_probe(struct platform_device *dev)
if (!ret)
return 0;
- clk_put(clk32k);
+err_ioremap:
+ release_resource(&tc6387xb->rscr);
err_resource:
+ clk_put(clk32k);
+err_no_clk:
+err_no_irq:
+ kfree(tc6387xb);
return ret;
}
@@ -195,3 +253,4 @@ MODULE_DESCRIPTION("Toshiba TC6387XB core driver");
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Ian Molton");
MODULE_ALIAS("platform:tc6387xb");
+
diff --git a/drivers/mfd/tc6393xb.c b/drivers/mfd/tc6393xb.c
index 1429a73..a44b6b0 100644
--- a/drivers/mfd/tc6393xb.c
+++ b/drivers/mfd/tc6393xb.c
@@ -136,10 +136,6 @@ static int tc6393xb_nand_enable(struct platform_device *nand)
return 0;
}
-static struct tmio_mmc_data tc6393xb_mmc_data = {
- .hclk = 24000000,
-};
-
static struct resource __devinitdata tc6393xb_nand_resources[] = {
{
.start = 0x1000,
@@ -165,11 +161,6 @@ static struct resource __devinitdata tc6393xb_mmc_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = 0x200,
- .end = 0x2ff,
- .flags = IORESOURCE_MEM,
- },
- {
.start = IRQ_TC6393_MMC,
.end = IRQ_TC6393_MMC,
.flags = IORESOURCE_IRQ,
@@ -346,6 +337,50 @@ int tc6393xb_lcd_mode(struct platform_device *fb,
}
EXPORT_SYMBOL(tc6393xb_lcd_mode);
+static int tc6393xb_mmc_enable(struct platform_device *mmc)
+{
+ struct platform_device *dev = to_platform_device(mmc->dev.parent);
+ struct tc6393xb *tc6393xb = platform_get_drvdata(dev);
+
+ tmio_core_mmc_enable(tc6393xb->scr + 0x200,
+ tc6393xb_mmc_resources[0].start & 0xfffe);
+
+ return 0;
+}
+
+static int tc6393xb_mmc_resume(struct platform_device *mmc)
+{
+ struct platform_device *dev = to_platform_device(mmc->dev.parent);
+ struct tc6393xb *tc6393xb = platform_get_drvdata(dev);
+
+ tmio_core_mmc_resume(tc6393xb->scr + 0x200,
+ tc6393xb_mmc_resources[0].start & 0xfffe);
+
+ return 0;
+}
+
+static void tc6393xb_mmc_pwr(struct platform_device *mmc, int state)
+{
+ struct platform_device *dev = to_platform_device(mmc->dev.parent);
+ struct tc6393xb *tc6393xb = platform_get_drvdata(dev);
+
+ tmio_core_mmc_pwr(tc6393xb->scr + 0x200, state);
+}
+
+static void tc6393xb_mmc_clk_div(struct platform_device *mmc, int state)
+{
+ struct platform_device *dev = to_platform_device(mmc->dev.parent);
+ struct tc6393xb *tc6393xb = platform_get_drvdata(dev);
+
+ tmio_core_mmc_clk_div(tc6393xb->scr + 0x200, state);
+}
+
+static struct tmio_mmc_data tc6393xb_mmc_data = {
+ .hclk = 24000000,
+ .set_pwr = tc6393xb_mmc_pwr,
+ .set_no_clk_div = tc6393xb_mmc_clk_div,
+};
+
static struct mfd_cell __devinitdata tc6393xb_cells[] = {
[TC6393XB_CELL_NAND] = {
.name = "tmio-nand",
@@ -355,6 +390,8 @@ static struct mfd_cell __devinitdata tc6393xb_cells[] = {
},
[TC6393XB_CELL_MMC] = {
.name = "tmio-mmc",
+ .enable = tc6393xb_mmc_enable,
+ .resume = tc6393xb_mmc_resume,
.driver_data = &tc6393xb_mmc_data,
.num_resources = ARRAY_SIZE(tc6393xb_mmc_resources),
.resources = tc6393xb_mmc_resources,
@@ -836,3 +873,4 @@ MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Ian Molton, Dmitry Baryshkov and Dirk Opfer");
MODULE_DESCRIPTION("tc6393xb Toshiba Mobile IO Controller");
MODULE_ALIAS("platform:tc6393xb");
+
diff --git a/drivers/mfd/tmio_core.c b/drivers/mfd/tmio_core.c
new file mode 100644
index 0000000..483fbbb
--- /dev/null
+++ b/drivers/mfd/tmio_core.c
@@ -0,0 +1,54 @@
+/*
+ * Toshiba TC6393XB SoC support
+ *
+ * Copyright(c) 2009 Ian Molton <spyro@f2s.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/mfd/tmio.h>
+
+int tmio_core_mmc_enable(void __iomem *cnf, unsigned long base)
+{
+ /* Enable the MMC/SD Control registers */
+ sd_config_write16(cnf + CNF_CMD, SDCREN);
+ sd_config_write32(cnf + CNF_CTL_BASE, base & 0xfffe);
+
+ /* Disable SD power during suspend */
+ sd_config_write8(cnf + CNF_PWR_CTL_3, 0x01);
+
+ /* The below is required but why? FIXME */
+ sd_config_write8(cnf + CNF_STOP_CLK_CTL, 0x1f);
+
+ /* Power down SD bus*/
+ sd_config_write8(cnf + CNF_PWR_CTL_2, 0x00);
+
+ return 0;
+}
+EXPORT_SYMBOL(tmio_core_mmc_enable);
+
+int tmio_core_mmc_resume(void __iomem *cnf, unsigned long base)
+{
+
+ /* Enable the MMC/SD Control registers */
+ sd_config_write16(cnf + CNF_CMD, SDCREN);
+ sd_config_write32(cnf + CNF_CTL_BASE, base & 0xfffe);
+
+ return 0;
+}
+EXPORT_SYMBOL(tmio_core_mmc_resume);
+
+void tmio_core_mmc_pwr(void __iomem *cnf, int state)
+{
+ sd_config_write8(cnf + CNF_PWR_CTL_2, state ? 0x02 : 0x00);
+}
+EXPORT_SYMBOL(tmio_core_mmc_pwr);
+
+void tmio_core_mmc_clk_div(void __iomem *cnf, int state)
+{
+ sd_config_write8(cnf + CNF_SD_CLK_MODE, state ? 1 : 0);
+}
+EXPORT_SYMBOL(tmio_core_mmc_clk_div);
+
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 91991b4..e701732 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -46,7 +46,9 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host, int new_clock)
clk |= 0x100;
}
- sd_config_write8(host, CNF_SD_CLK_MODE, clk >> 22);
+ if (host->set_no_clk_div)
+ host->set_no_clk_div(host->pdev, (clk>>22) & 1);
+
sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & 0x1ff);
}
@@ -427,12 +429,13 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
/* Power sequence - OFF -> ON -> UP */
switch (ios->power_mode) {
case MMC_POWER_OFF: /* power down SD bus */
- sd_config_write8(host, CNF_PWR_CTL_2, 0x00);
+ if (host->set_pwr)
+ host->set_pwr(host->pdev, 0);
tmio_mmc_clk_stop(host);
break;
case MMC_POWER_ON: /* power up SD bus */
-
- sd_config_write8(host, CNF_PWR_CTL_2, 0x02);
+ if (host->set_pwr)
+ host->set_pwr(host->pdev, 1);
break;
case MMC_POWER_UP: /* start bus clock */
tmio_mmc_clk_start(host);
@@ -475,8 +478,8 @@ static int tmio_mmc_suspend(struct platform_device *dev, pm_message_t state)
ret = mmc_suspend_host(mmc, state);
/* Tell MFD core it can disable us now.*/
- if (!ret && cell->disable)
- cell->disable(dev);
+ if (!ret && cell->suspend)
+ cell->suspend(dev);
return ret;
}
@@ -485,21 +488,15 @@ static int tmio_mmc_resume(struct platform_device *dev)
{
struct mfd_cell *cell = (struct mfd_cell *)dev->dev.platform_data;
struct mmc_host *mmc = platform_get_drvdata(dev);
- struct tmio_mmc_host *host = mmc_priv(mmc);
int ret = 0;
/* Tell the MFD core we are ready to be enabled */
- if (cell->enable) {
- ret = cell->enable(dev);
+ if (cell->resume) {
+ ret = cell->resume(dev);
if (ret)
goto out;
}
- /* Enable the MMC/SD Control registers */
- sd_config_write16(host, CNF_CMD, SDCREN);
- sd_config_write32(host, CNF_CTL_BASE,
- (dev->resource[0].start >> host->bus_shift) & 0xfffe);
-
mmc_resume_host(mmc);
out:
@@ -514,17 +511,16 @@ static int __devinit tmio_mmc_probe(struct platform_device *dev)
{
struct mfd_cell *cell = (struct mfd_cell *)dev->dev.platform_data;
struct tmio_mmc_data *pdata;
- struct resource *res_ctl, *res_cnf;
+ struct resource *res_ctl;
struct tmio_mmc_host *host;
struct mmc_host *mmc;
int ret = -EINVAL;
- if (dev->num_resources != 3)
+ if (dev->num_resources != 2)
goto out;
res_ctl = platform_get_resource(dev, IORESOURCE_MEM, 0);
- res_cnf = platform_get_resource(dev, IORESOURCE_MEM, 1);
- if (!res_ctl || !res_cnf)
+ if (!res_ctl)
goto out;
pdata = cell->driver_data;
@@ -539,8 +535,12 @@ static int __devinit tmio_mmc_probe(struct platform_device *dev)
host = mmc_priv(mmc);
host->mmc = mmc;
+ host->pdev = dev;
platform_set_drvdata(dev, mmc);
+ host->set_pwr = pdata->set_pwr;
+ host->set_no_clk_div = pdata->set_no_clk_div;
+
/* SD control register space size is 0x200, 0x400 for bus_shift=1 */
host->bus_shift = resource_size(res_ctl) >> 10;
@@ -548,10 +548,6 @@ static int __devinit tmio_mmc_probe(struct platform_device *dev)
if (!host->ctl)
goto host_free;
- host->cnf = ioremap(res_cnf->start, resource_size(res_cnf));
- if (!host->cnf)
- goto unmap_ctl;
-
mmc->ops = &tmio_mmc_ops;
mmc->caps = MMC_CAP_4_BIT_DATA;
mmc->f_max = pdata->hclk;
@@ -562,23 +558,9 @@ static int __devinit tmio_mmc_probe(struct platform_device *dev)
if (cell->enable) {
ret = cell->enable(dev);
if (ret)
- goto unmap_cnf;
+ goto unmap_ctl;
}
- /* Enable the MMC/SD Control registers */
- sd_config_write16(host, CNF_CMD, SDCREN);
- sd_config_write32(host, CNF_CTL_BASE,
- (dev->resource[0].start >> host->bus_shift) & 0xfffe);
-
- /* Disable SD power during suspend */
- sd_config_write8(host, CNF_PWR_CTL_3, 0x01);
-
- /* The below is required but why? FIXME */
- sd_config_write8(host, CNF_STOP_CLK_CTL, 0x1f);
-
- /* Power down SD bus*/
- sd_config_write8(host, CNF_PWR_CTL_2, 0x00);
-
tmio_mmc_clk_stop(host);
reset(host);
@@ -586,14 +568,14 @@ static int __devinit tmio_mmc_probe(struct platform_device *dev)
if (ret >= 0)
host->irq = ret;
else
- goto unmap_cnf;
+ goto unmap_ctl;
disable_mmc_irqs(host, TMIO_MASK_ALL);
ret = request_irq(host->irq, tmio_mmc_irq, IRQF_DISABLED |
IRQF_TRIGGER_FALLING, "tmio-mmc", host);
if (ret)
- goto unmap_cnf;
+ goto unmap_ctl;
mmc_add_host(mmc);
@@ -605,8 +587,6 @@ static int __devinit tmio_mmc_probe(struct platform_device *dev)
return 0;
-unmap_cnf:
- iounmap(host->cnf);
unmap_ctl:
iounmap(host->ctl);
host_free:
@@ -626,7 +606,6 @@ static int __devexit tmio_mmc_remove(struct platform_device *dev)
mmc_remove_host(mmc);
free_irq(host->irq, host);
iounmap(host->ctl);
- iounmap(host->cnf);
mmc_free_host(mmc);
}
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 9fa9985..c676767 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -11,26 +11,6 @@
#include <linux/highmem.h>
-#define CNF_CMD 0x04
-#define CNF_CTL_BASE 0x10
-#define CNF_INT_PIN 0x3d
-#define CNF_STOP_CLK_CTL 0x40
-#define CNF_GCLK_CTL 0x41
-#define CNF_SD_CLK_MODE 0x42
-#define CNF_PIN_STATUS 0x44
-#define CNF_PWR_CTL_1 0x48
-#define CNF_PWR_CTL_2 0x49
-#define CNF_PWR_CTL_3 0x4a
-#define CNF_CARD_DETECT_MODE 0x4c
-#define CNF_SD_SLOT 0x50
-#define CNF_EXT_GCLK_CTL_1 0xf0
-#define CNF_EXT_GCLK_CTL_2 0xf1
-#define CNF_EXT_GCLK_CTL_3 0xf9
-#define CNF_SD_LED_EN_1 0xfa
-#define CNF_SD_LED_EN_2 0xfe
-
-#define SDCREN 0x2 /* Enable access to MMC CTL regs. (flag in COMMAND_REG)*/
-
#define CTL_SD_CMD 0x00
#define CTL_ARG_REG 0x04
#define CTL_STOP_INTERNAL_ACTION 0x08
@@ -110,7 +90,6 @@
struct tmio_mmc_host {
- void __iomem *cnf;
void __iomem *ctl;
unsigned long bus_shift;
struct mmc_command *cmd;
@@ -119,10 +98,16 @@ struct tmio_mmc_host {
struct mmc_host *mmc;
int irq;
+ /* Callbacks for clock / power control */
+ void (*set_pwr)(struct platform_device *host, int state);
+ void (*set_no_clk_div)(struct platform_device *host, int state);
+
/* pio related stuff */
struct scatterlist *sg_ptr;
unsigned int sg_len;
unsigned int sg_off;
+
+ struct platform_device *pdev;
};
#include <linux/io.h>
@@ -163,25 +148,6 @@ static inline void sd_ctrl_write32(struct tmio_mmc_host *host, int addr,
writew(val >> 16, host->ctl + ((addr + 2) << host->bus_shift));
}
-static inline void sd_config_write8(struct tmio_mmc_host *host, int addr,
- u8 val)
-{
- writeb(val, host->cnf + (addr << host->bus_shift));
-}
-
-static inline void sd_config_write16(struct tmio_mmc_host *host, int addr,
- u16 val)
-{
- writew(val, host->cnf + (addr << host->bus_shift));
-}
-
-static inline void sd_config_write32(struct tmio_mmc_host *host, int addr,
- u32 val)
-{
- writew(val, host->cnf + (addr << host->bus_shift));
- writew(val >> 16, host->cnf + ((addr + 2) << host->bus_shift));
-}
-
#include <linux/scatterlist.h>
#include <linux/blkdev.h>
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index 6b9c5d0..a206a8d 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -2,6 +2,8 @@
#define MFD_TMIO_H
#include <linux/fb.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
#define tmio_ioread8(addr) readb(addr)
#define tmio_ioread16(addr) readw(addr)
@@ -18,11 +20,42 @@
writew((val) >> 16, (addr) + 2); \
} while (0)
+#define CNF_CMD 0x04
+#define CNF_CTL_BASE 0x10
+#define CNF_INT_PIN 0x3d
+#define CNF_STOP_CLK_CTL 0x40
+#define CNF_GCLK_CTL 0x41
+#define CNF_SD_CLK_MODE 0x42
+#define CNF_PIN_STATUS 0x44
+#define CNF_PWR_CTL_1 0x48
+#define CNF_PWR_CTL_2 0x49
+#define CNF_PWR_CTL_3 0x4a
+#define CNF_CARD_DETECT_MODE 0x4c
+#define CNF_SD_SLOT 0x50
+#define CNF_EXT_GCLK_CTL_1 0xf0
+#define CNF_EXT_GCLK_CTL_2 0xf1
+#define CNF_EXT_GCLK_CTL_3 0xf9
+#define CNF_SD_LED_EN_1 0xfa
+#define CNF_SD_LED_EN_2 0xfe
+
+#define SDCREN 0x2 /* Enable access to MMC CTL regs. (flag in COMMAND_REG)*/
+
+#define sd_config_write8(a, b) tmio_iowrite8((b), (a))
+#define sd_config_write16(a, b) tmio_iowrite16((b), (a))
+#define sd_config_write32(a, b) tmio_iowrite32((b), (a))
+
+int tmio_core_mmc_enable(void __iomem *cnf, unsigned long base);
+int tmio_core_mmc_resume(void __iomem *cnf, unsigned long base);
+void tmio_core_mmc_pwr(void __iomem *cnf, int state);
+void tmio_core_mmc_clk_div(void __iomem *cnf, int state);
+
/*
* data for the MMC controller
*/
struct tmio_mmc_data {
const unsigned int hclk;
+ void (*set_pwr)(struct platform_device *host, int state);
+ void (*set_no_clk_div)(struct platform_device *host, int state);
};
/*
--
1.6.3.3
[-- Attachment #3: 0002-MFD-tc6393xb-fix-clock-frequency.patch --]
[-- Type: text/x-patch, Size: 921 bytes --]
From d6791f2b9a6178aa15edcc854148f9d733ea43a8 Mon Sep 17 00:00:00 2001
From: Ian Molton <ian@mnementh.co.uk>
Date: Sat, 26 Sep 2009 00:44:33 +0100
Subject: [PATCH 2/5] MFD: tc6393xb: fix clock frequency
This patch corrects the HCLK frequency in the tc6393xb driver, I believe that it uses 33MHz, based on the comments in the (poor) documentation I have.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
---
drivers/mfd/tc6393xb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/tc6393xb.c b/drivers/mfd/tc6393xb.c
index a44b6b0..40bb375 100644
--- a/drivers/mfd/tc6393xb.c
+++ b/drivers/mfd/tc6393xb.c
@@ -376,7 +376,7 @@ static void tc6393xb_mmc_clk_div(struct platform_device *mmc, int state)
}
static struct tmio_mmc_data tc6393xb_mmc_data = {
- .hclk = 24000000,
+ .hclk = 33000000,
.set_pwr = tc6393xb_mmc_pwr,
.set_no_clk_div = tc6393xb_mmc_clk_div,
};
--
1.6.3.3
[-- Attachment #4: 0003-MMC-tmio-mmc-Fix-clocking.patch --]
[-- Type: text/x-patch, Size: 1243 bytes --]
From afbf6ec6df3b5aed93abcfe8f86a32708d4e2ef3 Mon Sep 17 00:00:00 2001
From: Ian Molton <ian@mnementh.co.uk>
Date: Tue, 29 Sep 2009 12:52:03 +0100
Subject: [PATCH 3/5] MMC: tmio-mmc: Fix clocking
This patch alters the clock selection on tmio-mmc based hosts such that
it will select the clock closest in frequency to the desired frequency.
This should improve the accuracy of clock selection, particularly
during card detection.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
---
drivers/mmc/host/tmio_mmc.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index e701732..a4cdc0b 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -43,6 +43,15 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host, int new_clock)
for (clock = host->mmc->f_min, clk = 0x80000080;
new_clock >= (clock<<1); clk >>= 1)
clock <<= 1;
+
+ /* Round the clock to the closest available. This is required
+ * for some fussy cards that dont like to initialise below 400kHz
+ */
+ if (new_clock - clock >= (clock << 1) - new_clock) {
+ clk >>= 1; clock <<= 1;
+ }
+
+ /* Clock enable */
clk |= 0x100;
}
--
1.6.3.3
[-- Attachment #5: 0004-MMC-tmio-mmc-Fix-power-sequencing.patch --]
[-- Type: text/x-patch, Size: 1349 bytes --]
From 690e9aea8fcfb78c7fae07d4ccdcffda9cf4ef23 Mon Sep 17 00:00:00 2001
From: Ian Molton <ian@mnementh.co.uk>
Date: Tue, 29 Sep 2009 12:55:27 +0100
Subject: [PATCH 4/5] MMC: tmio-mmc: Fix power sequencing
This patch fixes power sequencing on tmio-mmc based hosts so that
the clock is enabled only once the bus has been powered up.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
---
drivers/mmc/host/tmio_mmc.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index a4cdc0b..f233867 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -435,18 +435,18 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
if (ios->clock)
tmio_mmc_set_clock(host, ios->clock);
- /* Power sequence - OFF -> ON -> UP */
+ /* Power sequence - OFF -> UP -> ON */
switch (ios->power_mode) {
case MMC_POWER_OFF: /* power down SD bus */
if (host->set_pwr)
host->set_pwr(host->pdev, 0);
tmio_mmc_clk_stop(host);
break;
- case MMC_POWER_ON: /* power up SD bus */
+ case MMC_POWER_UP: /* power up SD bus */
if (host->set_pwr)
host->set_pwr(host->pdev, 1);
break;
- case MMC_POWER_UP: /* start bus clock */
+ case MMC_POWER_ON: /* enable bus clock */
tmio_mmc_clk_start(host);
break;
}
--
1.6.3.3
[-- Attachment #6: 0005-MMC-Retry-initialisation-at-a-lower-frequency-if-it-.patch --]
[-- Type: text/x-patch, Size: 1291 bytes --]
From bc0e0adbc24cb7bf8c0119e65d43b42410ce316a Mon Sep 17 00:00:00 2001
From: Ian Molton <ian@mnementh.co.uk>
Date: Tue, 29 Sep 2009 13:39:29 +0100
Subject: [PATCH 5/5] MMC: Retry initialisation at a lower frequency if it times out
This patch retrys the MMC card initialisation at a lower frequency
if it fails. It is needed on certain tmio controllers with fussy cards.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
---
drivers/mmc/core/mmc.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 06084db..03e782f 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -295,13 +295,17 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
struct mmc_card *oldcard)
{
struct mmc_card *card;
- int err;
+ int err, slow_retry = 0;
u32 cid[4];
unsigned int max_dtr;
BUG_ON(!host);
WARN_ON(!host->claimed);
+retry:
+ if (slow_retry)
+ mmc_set_clock(host, host->f_min);
+
/*
* Since we're changing the OCR value, we seem to
* need to tell some cards to go back to the idle
@@ -464,6 +468,11 @@ free_card:
mmc_remove_card(card);
err:
+ if (err == -ETIMEDOUT && host->f_min < 400000) {
+ slow_retry = 1;
+ goto retry;
+ }
+
return err;
}
--
1.6.3.3
^ permalink raw reply related
* [LTP] IMA tcb policy
From: Mimi Zohar @ 2009-09-29 12:52 UTC (permalink / raw)
To: ltp-list
Dependency section update.
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Index: ltp-full-20090831/testcases/kernel/security/integrity/ima/README
===================================================================
--- ltp-full-20090831.orig/testcases/kernel/security/integrity/ima/README
+++ ltp-full-20090831/testcases/kernel/security/integrity/ima/README
@@ -46,11 +46,13 @@ CONFIG_IMA_LSM_RULES=y
Dependency
----------
-The testsuite is dependent on the default policy being enabled, which
+The testsuite is dependent on the default TCB policy being enabled, which
measures all executables, all files mmapped for execute and all files
-open for read by root. If the default policy has been replaced, loading
-another measurement policy will fail, as the policy may only be replaced
-once per boot. Some of the policy dependency tests might also fail as well.
+open for read by root. For kernels 2.6.31 and greater, enable the
+trusted computing base(TCB) policy using the ima_tcb=1 boot parameter.
+If the TCB policy has been replaced, loading another measurement
+policy will fail, as the policy may only be replaced once per boot.
+Some of the policy dependency tests might also fail as well.
ima_tpm.sh: test02, verifying the PCR-10 value, requires a hard reboot.
[On Ubuntu, before running the ltp tests, disable /etc/init.d/kexec-load
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply
* Re: [PATCH] x86: Use __builtin_memset and __builtin_memcpy for memset/memcpy
From: Arjan van de Ven @ 2009-09-29 12:53 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, mingo, tglx, hpa, torvalds
In-Reply-To: <200909291444.06422.arnd@arndb.de>
On Tue, 29 Sep 2009 14:44:06 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> >
>
> The patch looks good, but is there a reason to keep it architecture
> specific? I would guess that the same logic applies to all
> architectures with gcc-4.x and could be put into
> include/linux/compiler-gcc4.h.
there are some requirements on the architecture for this to work....
and as always with compiler things, the tradeoffs and how well it works
will vary per architecture.
If the architectures in large majority make this switch we could move it
generic... but it's a bit early for that.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* [U-Boot] Does u-boot have support for a usb-ethernet adapter:
From: Remy Bohmer @ 2009-09-29 12:52 UTC (permalink / raw)
To: u-boot
In-Reply-To: <6C1B21044F854B46BB6245E0D185431B0F0673E895@SGPMBX01.APAC.bosch.com>
Hi,
2009/9/29 Harsh Goel (RBEI/ECB4) <Harsh.Goel@in.bosch.com>:
> Does u-boot have support for a usb-ethernet adapter:
>
> http://git.denx.de/?p=u-boot/u-boot-usb.git;a=commit;h=79c130f4a7af3ab4de041d60afa4e2fc1ec0c9ef
> i found at the following link that u-boot have support for usb-ethernet adapter.
Yep, these patches make the device running U-boot as an USB ethernet
adapter itself.
> But it is not working for me .
> Please help me to sort out this issue.
>
> Detail:
>
> I am able to ping my host from device but it connectivity stays only for some time then goes off.
U-boot does not work with interrupts, and there is only one single
thread running at any instance of time.
So, U-boot can only handle 1 thing at a time, so similar to any other
network driver in U-boot, the USB ethernet interface will perform
these steps:
1. Pull the VBUS line to announce itself to the host
2. Host will enumerate the device and load the drivers.
3. Once the network is brought up, U-boot is capable of doing some
network action (like ping, TFTP, DHCP etc)
4. The VBUS is pulled down again to allow U-boot to do something else,
like handling terminal keys or other commands.
This can certainly be improved, but that would require continuously
polling for interrupts from the mainloop. This would be different
compared to all other network drivers, so it was not chosen to do so
at the time we wrote these layers.
Patches are welcome!
> Please also tell how get gatewayip also.
Good question... I do not remember if this was implemented... I have to check.
Remy
^ 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.