* Re: Request (2nd) for unicore32 architecture codes to merge into linux-next
From: Thomas Gleixner @ 2011-02-06 22:06 UTC (permalink / raw)
To: Guan Xuetao
Cc: sfr, Arnd Bergmann, gregkh, jbarnes, dmitry.torokhov, dtor,
linux-arch, linux-kernel, linux-next
In-Reply-To: <01c701cbba0f$08185800$18490800$@mprc.pku.edu.cn>
On Sat, 22 Jan 2011, Guan Xuetao wrote:
> Hi, I want to merge unicore32 repo into linux-next tree, the
> position is (unicore32 branch):
Sorry for late reply.
> arch/unicore32/kernel/time.c | 148 +++++
static struct clock_event_device ckevt_puv3_osmr0 ...
#ifdef CONFIG_ARCH_FPGA
.shift = 18, /* correct shift val: 16, but warn_on_slowpath */
#else
.shift = 30,
#endif
....
ckevt_puv3_osmr0.mult =
div_sc(CLOCK_TICK_RATE, NSEC_PER_SEC, ckevt_puv3_osmr0.shift);
Please use the function which calculates the optimizes mult/shift
values for you depending on the clock frequency.
clockevents_calc_mult_shift() is your friend.
> arch/unicore32/kernel/irq.c | 426 +++++++++++++
Please convert your irq_chips to the new function pointers:
.mask -> .irq_mask
...
The new functions replace the "unsigned int irq" argument with
"struct irq_data *d".
So conversion for your chips is simply
s/unsigned int irq/struct irq_data *d/
and
s/irq/d->irq/ in the implementation.
Then your arch should select: GENERIC_HARDIRQS_NO_DEPRECATED
Otherwise I'm happy with your irq and time related patches.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 2/2] git-p4: Add copy detection support
From: Pete Wyckoff @ 2011-02-06 22:05 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <AANLkTi=Awi6d77QcbbZ2rDTv6LpP+qjsReJ5=4NyhUBz@mail.gmail.com>
vitor.hda@gmail.com wrote on Sun, 06 Feb 2011 17:25 +0000:
> Hi Pete,
>
> On Sun, Feb 6, 2011 at 12:25 AM, Pete Wyckoff <pw@padd.com> wrote:
> > You can use integrate -t to force the filetype even if the file
> > already existed, and skip the whole execbit change.
>
> (Copying help text:
> The -t flag makes the source file's filetype propagate to the target
> file. Normally, the target file retains its previous filetype.
> Newly branched files always use the source file's filetype. The
> filetype can still be changed before 'p4 submit' with 'p4 reopen'.
> )
>
> Since in git we're only considering newly branched files, I think in
> this case "-t" will not add anything. In fact, what is being done here
> is detecting exec bit changes from source to target files - we're not
> trying to force P4 to use the source's exec bit. Do you agree?
That sounds fine to me. The code seemed to indicate that
sometimes the destination file exists.
> + elif modifier == "C":
> + src, dest = diff['src'], diff['dst']
> + p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
> + if diff['src_sha1'] != diff['dst_sha1']:
> + p4_system("edit \"%s\"" % (dest))
> + if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
> + filesToChangeExecBit[dest] = diff['dst_mode']
> + os.unlink(dest)
> + editedFiles.add(dest)
If you're happy the dest never exists, you may be able to get rid
of the edit step and the mode-change check entirely. As long as
you've tested this, you're the expert here. The change makes
sense overall.
-- Pete
^ permalink raw reply
* Re: Supermicro X8DTH-6: Only ~250MiB/s from RAID<->RAID over 10GbE?
From: Stan Hoeppner @ 2011-02-06 22:01 UTC (permalink / raw)
To: Justin Piszcz
Cc: Dr. David Alan Gilbert, Emmanuel Florac, linux-kernel, linux-scsi,
linux-net, Alan Piszcz
In-Reply-To: <alpine.DEB.2.00.1102060515230.28109@p34.internal.lan>
Justin Piszcz put forth on 2/6/2011 4:16 AM:
> Workflow process-
>
> Migrate data from old/legacy RAID sets to new ones, possibly also 2TB->3TB, so
> the faster the transfer speed, the better.
This type of data migration is probably going to include many many files of
various sizes from small to large. You have optimized your system performance
only for individual large file xfers. Thus, when you go to copy directories
containing hundreds or thousands of files of various sizes, you will likely see
much lower throughput using a single copy stream. Thus if you want to keep that
10 GbE pipe full, you'll likely need to run multiple copies in parallel, one per
large parent directory. Or, run a single copy from say, 10 legacy systems to
one new system simultaneously, etc.
Given this situation, you may want to consider tar'ing up entire directories
with gz or bz compression, if you have enough free space on the legacy machines,
and copying the tarballs to the new system. This will maximize your throughput,
although I don't know if it will decrease your total work flow completion time,
which should really be your overall goal.
--
Stan
^ permalink raw reply
* Re: [PATCH] git pull: Remove option handling done by fetch
From: Jens Lehmann @ 2011-02-06 21:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List, Jonathan Nieder
In-Reply-To: <7vipwwx56r.fsf@alter.siamese.dyndns.org>
Am 06.02.2011 21:45, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Yes, but isn't that exactly what the pull man-page says? Quote:
>> "Options meant for git pull itself and the underlying git merge
>> must be given before the options meant for git fetch."
>
> Yes, it says that, and I think that was a weasely way to say "the command
> line parser in git-pull is broken". The lines you are removing was from
> the patch that fixed that breakage, aren't they?
Nope, they were from the patch where I taught "git fetch" the
"--recurse-submodules" option and was not aware at that time that
"git pull" should just pass on almost all fetch options (the only
exceptions to that rule being -q, -v, -n and --progress). The thing
I had in mind was to later pass the same "--recurse-submodules"
option to the merge command too (when I finished implementing that
option). But when I understood later that pull handles the fetch
options in an interesting way I noticed that it would depend on the
order of options given if the "--recurse-submodules" would then be
passed to both fetch and merge or just to fetch, which will lead to
an interesting and unintuitive behavior I was not eager to expose.
So yes, I hit the strangeness of the "git pull" option parsing, but
decided to not mess it up further by adding another option to the
ones it does handle differently but play by the rules which are
used now (The other possibility would have been to document it
as a new option to "git pull", but that would have lead to the
problem I described earlier when merge will learn that option too).
So I have no strong feelings about this patch but believe it is the
right thing to do as long as "git pull" handles its options the way
it does. But looking at the confusion that option handling caused
I think it might be a worthwhile idea to overhaul it.
(CCed Jonathan, as he is the author of the lines I quoted)
^ permalink raw reply
* Re: [PATCH -next] Documentation: Improve crashkernel= description
From: Simon Horman @ 2011-02-06 21:57 UTC (permalink / raw)
To: Ahmed S. Darwish
Cc: Randy Dunlap, Vivek Goyal, Haren Myneni, Eric Biederman, kexec,
LKML, linux-doc
In-Reply-To: <20110206154108.GA16542@laptop>
On Sun, Feb 06, 2011 at 05:41:08PM +0200, Ahmed S. Darwish wrote:
> (Also applicable over 2.6.38-rc3)
>
> Had to explore two C code files to make sense of the 'crashkernel='
> kernel parameter values. Improve the situation.
>
> Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
> ---
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 89835a4..8f26b42 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -545,9 +545,12 @@ and is between 256 and 4096 characters. It is defined in the file
> Format:
> <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
>
> - crashkernel=nn[KMG]@ss[KMG]
> - [KNL] Reserve a chunk of physical memory to
> - hold a kernel to switch to with kexec on panic.
> + crashkernel=size[KMG][@offset[KMG]]
> + [KNL] Using kexec, Linux can switch to a 'crash kernel'
> + upon panic. This parameter reserves the physical
> + memory region [offset, offset + size] for that kernel
> + image. If the '@offset' part was ignored, Linux finds
> + a suitable crash image start address automatically.
I think this would be further improved as:
... If '@offset' is omitted then a suitable
offset is selected automatically.
>
> crashkernel=range1:size1[,range2:size2,...][@offset]
> [KNL] Same as above, but depends on the memory
>
> regards,
>
> --
> Darwish
> http://darwish.07.googlepages.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH -next] Documentation: Improve crashkernel= description
From: Simon Horman @ 2011-02-06 21:57 UTC (permalink / raw)
To: Ahmed S. Darwish
Cc: linux-doc, kexec, LKML, Haren Myneni, Randy Dunlap,
Eric Biederman, Vivek Goyal
In-Reply-To: <20110206154108.GA16542@laptop>
On Sun, Feb 06, 2011 at 05:41:08PM +0200, Ahmed S. Darwish wrote:
> (Also applicable over 2.6.38-rc3)
>
> Had to explore two C code files to make sense of the 'crashkernel='
> kernel parameter values. Improve the situation.
>
> Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
> ---
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 89835a4..8f26b42 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -545,9 +545,12 @@ and is between 256 and 4096 characters. It is defined in the file
> Format:
> <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
>
> - crashkernel=nn[KMG]@ss[KMG]
> - [KNL] Reserve a chunk of physical memory to
> - hold a kernel to switch to with kexec on panic.
> + crashkernel=size[KMG][@offset[KMG]]
> + [KNL] Using kexec, Linux can switch to a 'crash kernel'
> + upon panic. This parameter reserves the physical
> + memory region [offset, offset + size] for that kernel
> + image. If the '@offset' part was ignored, Linux finds
> + a suitable crash image start address automatically.
I think this would be further improved as:
... If '@offset' is omitted then a suitable
offset is selected automatically.
>
> crashkernel=range1:size1[,range2:size2,...][@offset]
> [KNL] Same as above, but depends on the memory
>
> regards,
>
> --
> Darwish
> http://darwish.07.googlepages.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [xen-unstable test] 5664: regressions - FAIL
From: xen.org @ 2011-02-06 21:56 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 5664 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/5664/
Regressions :-(
Tests which did not succeed and are blocking:
build-amd64-oldkern 4 xen-build fail REGR. vs. 5640
build-amd64 4 xen-build fail REGR. vs. 5640
build-i386-oldkern 4 xen-build fail REGR. vs. 5640
build-i386 4 xen-build fail REGR. vs. 5640
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a
test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a
test-amd64-amd64-win 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a
test-amd64-i386-pair 1 xen-build-check(1) blocked n/a
test-amd64-i386-pv 1 xen-build-check(1) blocked n/a
test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a
test-amd64-i386-win 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-win 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-xl-credit2 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-xl-win 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a
test-i386-i386-pair 1 xen-build-check(1) blocked n/a
test-i386-i386-pv 1 xen-build-check(1) blocked n/a
test-i386-i386-win 1 xen-build-check(1) blocked n/a
test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a
test-i386-i386-xl 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-win 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a
version targeted for testing:
xen 7ada6faef565
baseline version:
xen 4bdb78db22b6
------------------------------------------------------------
People who touched revisions under test:
Allen Kay <allen.m.kay@intel.com>
Andre Przywara <andre.przywara@amd.com>
George Dunlap <george.dunlap@eu.citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Juergen Gross <juergen.gross@ts.fujitsu.com>
Keir Fraser <keir@xen.org>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Stephen Smalley <sds@tycho.nsa.gov>
Wei Huang <wei.huang2@amd.com>
Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------
jobs:
build-i386-xcpkern pass
build-amd64 fail
build-i386 fail
build-amd64-oldkern fail
build-i386-oldkern fail
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl blocked
test-amd64-i386-xl blocked
test-i386-i386-xl blocked
test-amd64-xcpkern-i386-xl blocked
test-i386-xcpkern-i386-xl blocked
test-amd64-i386-rhel6hvm-amd blocked
test-amd64-xcpkern-i386-rhel6hvm-amd blocked
test-amd64-i386-xl-credit2 blocked
test-amd64-xcpkern-i386-xl-credit2 blocked
test-amd64-i386-rhel6hvm-intel blocked
test-amd64-xcpkern-i386-rhel6hvm-intel blocked
test-amd64-i386-xl-multivcpu blocked
test-amd64-xcpkern-i386-xl-multivcpu blocked
test-amd64-amd64-pair blocked
test-amd64-i386-pair blocked
test-i386-i386-pair blocked
test-amd64-xcpkern-i386-pair blocked
test-i386-xcpkern-i386-pair blocked
test-amd64-amd64-pv blocked
test-amd64-i386-pv blocked
test-i386-i386-pv blocked
test-amd64-xcpkern-i386-pv blocked
test-i386-xcpkern-i386-pv blocked
test-amd64-i386-win-vcpus1 blocked
test-amd64-i386-xl-win-vcpus1 blocked
test-amd64-amd64-win blocked
test-amd64-i386-win blocked
test-i386-i386-win blocked
test-amd64-xcpkern-i386-win blocked
test-i386-xcpkern-i386-win blocked
test-amd64-amd64-xl-win blocked
test-i386-i386-xl-win blocked
test-amd64-xcpkern-i386-xl-win blocked
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
changeset: 22878:7ada6faef565
tag: tip
user: Keir Fraser <keir@xen.org>
date: Sun Feb 06 17:26:31 2011 +0000
hvm: fix XSAVE leaf 0 EBX size calculation
Fixes a size calculation bug when enabled bits in XFEATURE_MASK (xcr0)
aren't contiguous.
Current for_loop will stop when xcr0 feature bit is 0. But in reality,
the bits can be non-contiguous. One example is that LWP is bit 62 on
AMD platform. This patch iterates through all bits to calculate the
size for enabled features.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
changeset: 22877:575d2f40acc4
user: Keir Fraser <keir@xen.org>
date: Sun Feb 06 17:22:44 2011 +0000
trace: Change trace_var argument to void*, to match __trace_var
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
changeset: 22876:93212e5c88f6
user: Keir Fraser <keir@xen.org>
date: Sun Feb 06 17:21:17 2011 +0000
hvm_op: Clean up new mem_access and inject_trap ops.
Firstly, they are only for use from privileged entities, so mark them
as usable only by code defining __XEN_TOOLS__.
Secondly, the check for must-not-operate-on-myself can be done more
cleanly.
Signed-off-by: Keir Fraser <keir@xen.org>
changeset: 22875:1f588baf1242
user: Keir Fraser <keir@xen.org>
date: Sun Feb 06 17:10:31 2011 +0000
xsm/flask: Fix permission tables
At some point, it seems that someone manually added Flask permission
definitions to one header file without updating the corresponding
policy configuration or the other related table. The end result is
that we can get uninterpretable AVC messages like this:
# xl dmesg | grep avc
(XEN) avc: denied { 0x4000000 } for domid=0
scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t
tclass=domain
Fix this by updating the flask config and regenerating the headers
from it. In the future, this can be further improved by integrating
the automatic generation of the headers into the build process as is
presently done in SELinux.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
changeset: 22874:24a4487c9bef
user: Keir Fraser <keir@xen.org>
date: Sun Feb 06 17:09:32 2011 +0000
xsm: Fix compilation error (unused variable)
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
changeset: 22873:186162762071
user: Keir Fraser <keir@xen.org>
date: Sun Feb 06 17:03:09 2011 +0000
hvm amd: Fix 32bit guest VM save/restore issues associated with SYSENTER MSRs
This patch turn-on SYSENTER MSRs interception for 32bit guest VMs on
AMD CPUs. With it, hvm_svm.guest_sysenter_xx fields always contain the
canonical version of SYSENTER MSRs and are used in guest save/restore.
The data fields in VMCB save area are updated as necessary.
Reported-by: James Harper <james.harper@bendigoit.com.au>
Signed-off-by: Wei Huang <wei.huang2@amd.com>
changeset: 22872:cba9a84d32fb
user: Keir Fraser <keir@xen.org>
date: Sun Feb 06 16:54:01 2011 +0000
amd iommu: Fix a xen crash after pci-attach
pci-detach triggers IO page table deallocation if the last passthru
device has been removed from pdev list, and this will result a BUG on
amd systems for next pci-attach. This patch fixes this issue.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
changeset: 22871:23f60ba52fff
user: Keir Fraser <keir@xen.org>
date: Sun Feb 06 16:07:27 2011 +0000
cpupool: Check for memory allocation failure on switching schedulers
When switching schedulers on a physical cpu due to a cpupool operation
check for a potential memory allocation failure and stop the operation
gracefully.
Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
changeset: 22870:544b103b4d97
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Fri Feb 04 18:47:39 2011 +0000
libxl: vncviewer: make autopass work properly
The file we write the vnc password to must be rewound back to the
beginning, or the vnc viewer will simply get EOF.
When the syscalls for communicating the password to the vnc client
fail, bomb out with an error messsage rather than blundering on (and
probably producing a spurious password prompt).
Following this patch, xl vncviewer --autopass works, provided the qemu
patch for writing the password to xenstore has also been applied.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 22869:c77353cb2ebb
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Fri Feb 04 18:47:20 2011 +0000
libxl: vncviewer: unconditionally read listen port address and password
The /local/domain/DOMID/device/vfb/0/backend path is irrelevant.
libxl does not create it, so the branch would never be taken.
Instead, simply read the target paths of interest.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 22868:3cd9f9db5c21
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Fri Feb 04 18:46:22 2011 +0000
libxl: vncviewer: fix use-after-free
This bug can prevent xl vncviewer from working at all.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 22867:f4d29a2c45ca
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Fri Feb 04 18:46:00 2011 +0000
libxl: actually print an error when execve (in libxl__exec) fails
The header comment says libxl__exec logs errors. So it should do so.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 22866:ed9ef3b07d2a
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Fri Feb 04 18:45:26 2011 +0000
libxl: SECURITY: always honour request for vnc password
qemu only sets a password on its vnc display if the value for the -vnc
option has the ",password" modifier. The code for constructing
qemu-dm options was broken and only added this modifier for one of the
cases.
Unfortunately there does not appear to be any code for passing the vnc
password to upstream qemu (ie, in the case where
libxl_build_device_model_args_new is called). To avoid accidentally
running the domain without a password, check for this situation and
fail an assertion. This will have to be revisited after 4.1.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 22865:25d7e5e2ceea
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Fri Feb 04 18:43:53 2011 +0000
QEMU_TAG update
changeset: 22864:d5863e86c05b
user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date: Fri Feb 04 18:29:55 2011 +0000
libxl: fix console autoconnect with pygrub, by invoking xenconsole twice
When using pygrub we have to connect to the console twice: once at the
beginning to connect to pygrub and a second time after creating the pv
console to connect to the guest's console.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 22863:6399079b44f3
user: Stefano Stabellini <sstabellini@xensource.com>
date: Fri Feb 04 17:41:37 2011 +0000
Update list of VT-D maintainers.
changeset: 22862:068b3f19ef9a
user: Andre Przywara <andre.przywara@amd.com>
date: Fri Feb 04 17:32:39 2011 +0000
xl: fix broken xl vcpu-list output (tool hangs on large machines)
The algorithm for printing the CPU affinity in a condensed way
looks for a set bit in a zero-byte:
for (i = 0; !(pcpumap & 1); ++i, pcpumap >>= 1)
Looking at the code I found that it is entirely broken if more than 8
CPUs are used. Beside that endless loop issue the output is totally
bogus except for the "any CPU" case, which is handled explicitly earlier.
I tried to fix it, but the whole approach does not work if the outer
loops actually iterates (executing more than once).
This fix reimplements the whole algorithm in a clean (though not much
optimized way). It survived some unit-testing.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 22861:4bdb78db22b6
user: Allen Kay <allen.m.kay@intel.com>
date: Wed Feb 02 17:06:36 2011 +0000
libxl: pass gfx_passthru parameter to QEMU
Pass gfx_passthru parameter to QEMU. Keep it boolean for now as QEMU
does not expect any other integer value.
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)
^ permalink raw reply
* [PATCH][trivial] Remove duplicate inclusion of wlc_event.h in drivers/staging/brcm80211/sys/wlc_mac80211.c
From: Jesper Juhl @ 2011-02-06 21:52 UTC (permalink / raw)
To: devel
Cc: linux-kernel, linux-wireless, Jason Cooper, Greg Kroah-Hartman,
Arend van Spriel, Roland Vossen, Dowan Kim, Henry Ptasinski,
Brett Rudley, trivial
We include wlc_event.h twice in
drivers/staging/brcm80211/sys/wlc_mac80211.c
Once is enough.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
wlc_mac80211.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/brcm80211/sys/wlc_mac80211.c b/drivers/staging/brcm80211/sys/wlc_mac80211.c
index a130386..0a46d44 100644
--- a/drivers/staging/brcm80211/sys/wlc_mac80211.c
+++ b/drivers/staging/brcm80211/sys/wlc_mac80211.c
@@ -47,7 +47,6 @@
#include <wlc_antsel.h>
#include <wlc_stf.h>
#include <wlc_ampdu.h>
-#include <wlc_event.h>
#include <wl_export.h>
#include "d11ucode_ext.h"
#include <wlc_alloc.h>
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* [patch 7/7] mn10300: Select GENERIC_HARDIRQS_NO_DEPRECATED
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
In-Reply-To: <20110206214441.438777646@linutronix.de>
[-- Attachment #1: mn10300-set-nodepr.patch --]
[-- Type: text/plain, Size: 491 bytes --]
All chips converted.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mn10300/Kconfig | 1 +
1 file changed, 1 insertion(+)
Index: linux-next/arch/mn10300/Kconfig
===================================================================
--- linux-next.orig/arch/mn10300/Kconfig
+++ linux-next/arch/mn10300/Kconfig
@@ -2,6 +2,7 @@ config MN10300
def_bool y
select HAVE_OPROFILE
select GENERIC_HARDIRQS
+ select GENERIC_HARDIRQS_NO_DEPRECATED
config AM33_2
def_bool n
^ permalink raw reply
* [patch 6/7] mn103000: asb2364: Convert FPGA irq_chip to new functions
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
In-Reply-To: <20110206214441.438777646@linutronix.de>
[-- Attachment #1: mn103000-asb2364-convert-fga-chip.patch --]
[-- Type: text/plain, Size: 1870 bytes --]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mn10300/unit-asb2364/irq-fpga.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
Index: linux-next/arch/mn10300/unit-asb2364/irq-fpga.c
===================================================================
--- linux-next.orig/arch/mn10300/unit-asb2364/irq-fpga.c
+++ linux-next/arch/mn10300/unit-asb2364/irq-fpga.c
@@ -17,38 +17,38 @@
/*
* FPGA PIC operations
*/
-static void asb2364_fpga_mask(unsigned int irq)
+static void asb2364_fpga_mask(struct irq_data *d)
{
- ASB2364_FPGA_REG_MASK(irq - NR_CPU_IRQS) = 0x0001;
+ ASB2364_FPGA_REG_MASK(d->irq - NR_CPU_IRQS) = 0x0001;
SyncExBus();
}
-static void asb2364_fpga_ack(unsigned int irq)
+static void asb2364_fpga_ack(struct irq_data *d)
{
- ASB2364_FPGA_REG_IRQ(irq - NR_CPU_IRQS) = 0x0001;
+ ASB2364_FPGA_REG_IRQ(d->irq - NR_CPU_IRQS) = 0x0001;
SyncExBus();
}
-static void asb2364_fpga_mask_ack(unsigned int irq)
+static void asb2364_fpga_mask_ack(struct irq_data *d)
{
- ASB2364_FPGA_REG_MASK(irq - NR_CPU_IRQS) = 0x0001;
+ ASB2364_FPGA_REG_MASK(d->irq - NR_CPU_IRQS) = 0x0001;
SyncExBus();
- ASB2364_FPGA_REG_IRQ(irq - NR_CPU_IRQS) = 0x0001;
+ ASB2364_FPGA_REG_IRQ(d->irq - NR_CPU_IRQS) = 0x0001;
SyncExBus();
}
-static void asb2364_fpga_unmask(unsigned int irq)
+static void asb2364_fpga_unmask(struct irq_data *d)
{
- ASB2364_FPGA_REG_MASK(irq - NR_CPU_IRQS) = 0x0000;
+ ASB2364_FPGA_REG_MASK(d->irq - NR_CPU_IRQS) = 0x0000;
SyncExBus();
}
static struct irq_chip asb2364_fpga_pic = {
.name = "fpga",
- .ack = asb2364_fpga_ack,
- .mask = asb2364_fpga_mask,
- .mask_ack = asb2364_fpga_mask_ack,
- .unmask = asb2364_fpga_unmask,
+ .irq_ack = asb2364_fpga_ack,
+ .irq_mask = asb2364_fpga_mask,
+ .irq_mask_ack = asb2364_fpga_mask_ack,
+ .irq_unmask = asb2364_fpga_unmask,
};
/*
^ permalink raw reply
* [patch 5/7] mn10300: Convert ipi irq_chip to new functions
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
In-Reply-To: <20110206214441.438777646@linutronix.de>
[-- Attachment #1: mn10300-convert-ip-chip.patch --]
[-- Type: text/plain, Size: 2409 bytes --]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mn10300/kernel/smp.c | 30 ++++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
Index: linux-next/arch/mn10300/kernel/smp.c
===================================================================
--- linux-next.orig/arch/mn10300/kernel/smp.c
+++ linux-next/arch/mn10300/kernel/smp.c
@@ -113,15 +113,17 @@ static void init_ipi(void);
*/
static void mn10300_ipi_disable(unsigned int irq);
static void mn10300_ipi_enable(unsigned int irq);
-static void mn10300_ipi_ack(unsigned int irq);
-static void mn10300_ipi_nop(unsigned int irq);
+static void mn10300_ipi_chip_disable(struct irq_data *d);
+static void mn10300_ipi_chip_enable(struct irq_data *d);
+static void mn10300_ipi_ack(struct irq_data *d);
+static void mn10300_ipi_nop(struct irq_data *d);
static struct irq_chip mn10300_ipi_type = {
.name = "cpu_ipi",
- .disable = mn10300_ipi_disable,
- .enable = mn10300_ipi_enable,
- .ack = mn10300_ipi_ack,
- .eoi = mn10300_ipi_nop
+ .irq_disable = mn10300_ipi_chip_disable,
+ .irq_enable = mn10300_ipi_chip_enable,
+ .irq_ack = mn10300_ipi_ack,
+ .irq_eoi = mn10300_ipi_nop
};
static irqreturn_t smp_reschedule_interrupt(int irq, void *dev_id);
@@ -236,6 +238,11 @@ static void mn10300_ipi_enable(unsigned
arch_local_irq_restore(flags);
}
+static void mn10300_ipi_chip_enable(struct irq_data *d)
+{
+ mn10300_ipi_enable(d->irq);
+}
+
/**
* mn10300_ipi_disable - Disable an IPI
* @irq: The IPI to be disabled.
@@ -254,6 +261,12 @@ static void mn10300_ipi_disable(unsigned
arch_local_irq_restore(flags);
}
+static void mn10300_ipi_chip_disable(struct irq_data *d)
+{
+ mn10300_ipi_disable(d->irq);
+}
+
+
/**
* mn10300_ipi_ack - Acknowledge an IPI interrupt in the PIC
* @irq: The IPI to be acknowledged.
@@ -261,8 +274,9 @@ static void mn10300_ipi_disable(unsigned
* Clear the interrupt detection flag for the IPI on the appropriate interrupt
* channel in the PIC.
*/
-static void mn10300_ipi_ack(unsigned int irq)
+static void mn10300_ipi_ack(struct irq_data *d)
{
+ unsigned int irq = d->irq;
unsigned long flags;
u16 tmp;
@@ -276,7 +290,7 @@ static void mn10300_ipi_ack(unsigned int
* mn10300_ipi_nop - Dummy IPI action
* @irq: The IPI to be acted upon.
*/
-static void mn10300_ipi_nop(unsigned int irq)
+static void mn10300_ipi_nop(struct irq_data *d)
{
}
^ permalink raw reply
* [patch 4/7] mn10300: Convert serial irq_chip to new functions
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
In-Reply-To: <20110206214441.438777646@linutronix.de>
[-- Attachment #1: mn10300-convert-serial-irq-chip.patch --]
[-- Type: text/plain, Size: 1109 bytes --]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mn10300/kernel/mn10300-serial.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
Index: linux-next/arch/mn10300/kernel/mn10300-serial.c
===================================================================
--- linux-next.orig/arch/mn10300/kernel/mn10300-serial.c
+++ linux-next/arch/mn10300/kernel/mn10300-serial.c
@@ -384,16 +384,21 @@ static void mn10300_serial_mask_ack(unsi
arch_local_irq_restore(flags);
}
-static void mn10300_serial_nop(unsigned int irq)
+static void mn10300_serial_chip_mask_ack(struct irq_data *d)
+{
+ mn10300_serial_mask_ack(d->irq);
+}
+
+static void mn10300_serial_nop(struct irq_data *d
{
}
static struct irq_chip mn10300_serial_pic = {
.name = "mnserial",
- .ack = mn10300_serial_mask_ack,
- .mask = mn10300_serial_mask_ack,
- .mask_ack = mn10300_serial_mask_ack,
- .unmask = mn10300_serial_nop,
+ .irq_ack = mn10300_serial_chip_mask_ack,
+ .irq_mask = mn10300_serial_chip_mask_ack,
+ .irq_mask_ack = mn10300_serial_chip_mask_ack,
+ .irq_unmask = mn10300_serial_nop,
};
^ permalink raw reply
* [patch 3/7] mn10300: Convert cpu irq_chips to new functions
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
In-Reply-To: <20110206214441.438777646@linutronix.de>
[-- Attachment #1: mn10300-convert-cpu-irq_chips.patch --]
[-- Type: text/plain, Size: 5205 bytes --]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mn10300/kernel/irq.c | 62 ++++++++++++++++++++++++----------------------
1 file changed, 33 insertions(+), 29 deletions(-)
Index: linux-next/arch/mn10300/kernel/irq.c
===================================================================
--- linux-next.orig/arch/mn10300/kernel/irq.c
+++ linux-next/arch/mn10300/kernel/irq.c
@@ -37,8 +37,9 @@ atomic_t irq_err_count;
/*
* MN10300 interrupt controller operations
*/
-static void mn10300_cpupic_ack(unsigned int irq)
+static void mn10300_cpupic_ack(struct irq_chip *d)
{
+ unsigned int irq = d->irq;
unsigned long flags;
u16 tmp;
@@ -61,13 +62,14 @@ static void __mask_and_set_icr(unsigned
arch_local_irq_restore(flags);
}
-static void mn10300_cpupic_mask(unsigned int irq)
+static void mn10300_cpupic_mask(struct irq_chip *d)
{
- __mask_and_set_icr(irq, GxICR_LEVEL, 0);
+ __mask_and_set_icr(d->irq, GxICR_LEVEL, 0);
}
-static void mn10300_cpupic_mask_ack(unsigned int irq)
+static void mn10300_cpupic_mask_ack(struct irq_chip *d)
{
+ unsigned int irq = d->irq;
#ifdef CONFIG_SMP
unsigned long flags;
u16 tmp;
@@ -85,7 +87,7 @@ static void mn10300_cpupic_mask_ack(unsi
tmp2 = GxICR(irq);
irq_affinity_online[irq] =
- any_online_cpu(*irq_desc[irq].affinity);
+ any_online_cpu(*d->affinity);
CROSS_GxICR(irq, irq_affinity_online[irq]) =
(tmp & (GxICR_LEVEL | GxICR_ENABLE)) | GxICR_DETECT;
tmp = CROSS_GxICR(irq, irq_affinity_online[irq]);
@@ -97,13 +99,14 @@ static void mn10300_cpupic_mask_ack(unsi
#endif /* CONFIG_SMP */
}
-static void mn10300_cpupic_unmask(unsigned int irq)
+static void mn10300_cpupic_unmask(struct irq_chip *d)
{
- __mask_and_set_icr(irq, GxICR_LEVEL, GxICR_ENABLE);
+ __mask_and_set_icr(d->irq, GxICR_LEVEL, GxICR_ENABLE);
}
-static void mn10300_cpupic_unmask_clear(unsigned int irq)
+static void mn10300_cpupic_unmask_clear(struct irq_chip *d)
{
+ unsigned int irq = d->irq;
/* the MN10300 PIC latches its interrupt request bit, even after the
* device has ceased to assert its interrupt line and the interrupt
* channel has been disabled in the PIC, so for level-triggered
@@ -121,7 +124,7 @@ static void mn10300_cpupic_unmask_clear(
} else {
tmp = GxICR(irq);
- irq_affinity_online[irq] = any_online_cpu(*irq_desc[irq].affinity);
+ irq_affinity_online[irq] = any_online_cpu(*d->affinity);
CROSS_GxICR(irq, irq_affinity_online[irq]) = (tmp & GxICR_LEVEL) | GxICR_ENABLE | GxICR_DETECT;
tmp = CROSS_GxICR(irq, irq_affinity_online[irq]);
}
@@ -134,7 +137,8 @@ static void mn10300_cpupic_unmask_clear(
#ifdef CONFIG_SMP
static int
-mn10300_cpupic_setaffinity(unsigned int irq, const struct cpumask *mask)
+mn10300_cpupic_setaffinity(struct irq_chip *d, const struct cpumask *mask,
+ bool force)
{
unsigned long flags;
int err;
@@ -142,7 +146,7 @@ mn10300_cpupic_setaffinity(unsigned int
flags = arch_local_cli_save();
/* check irq no */
- switch (irq) {
+ switch (d->irq) {
case TMJCIRQ:
case RESCHEDULE_IPI:
case CALL_FUNC_SINGLE_IPI:
@@ -181,7 +185,7 @@ mn10300_cpupic_setaffinity(unsigned int
break;
default:
- set_bit(irq, irq_affinity_request);
+ set_bit(d->irq, irq_affinity_request);
err = 0;
break;
}
@@ -202,15 +206,15 @@ mn10300_cpupic_setaffinity(unsigned int
* mask_ack() is provided), and mask_ack() just masks.
*/
static struct irq_chip mn10300_cpu_pic_level = {
- .name = "cpu_l",
- .disable = mn10300_cpupic_mask,
- .enable = mn10300_cpupic_unmask_clear,
- .ack = NULL,
- .mask = mn10300_cpupic_mask,
- .mask_ack = mn10300_cpupic_mask,
- .unmask = mn10300_cpupic_unmask_clear,
+ .name = "cpu_l",
+ .irq_disable = mn10300_cpupic_mask,
+ .irq_enable = mn10300_cpupic_unmask_clear,
+ .irq_ack = NULL,
+ .irq_mask = mn10300_cpupic_mask,
+ .irq_mask_ack = mn10300_cpupic_mask,
+ .irq_unmask = mn10300_cpupic_unmask_clear,
#ifdef CONFIG_SMP
- .set_affinity = mn10300_cpupic_setaffinity,
+ .irq_set_affinity = mn10300_cpupic_setaffinity,
#endif
};
@@ -220,15 +224,15 @@ static struct irq_chip mn10300_cpu_pic_l
* We use the latch clearing function of the PIC as the 'ACK' function.
*/
static struct irq_chip mn10300_cpu_pic_edge = {
- .name = "cpu_e",
- .disable = mn10300_cpupic_mask,
- .enable = mn10300_cpupic_unmask,
- .ack = mn10300_cpupic_ack,
- .mask = mn10300_cpupic_mask,
- .mask_ack = mn10300_cpupic_mask_ack,
- .unmask = mn10300_cpupic_unmask,
+ .name = "cpu_e",
+ .irq_disable = mn10300_cpupic_mask,
+ .irq_enable = mn10300_cpupic_unmask,
+ .irq_ack = mn10300_cpupic_ack,
+ .irq_mask = mn10300_cpupic_mask,
+ .irq_mask_ack = mn10300_cpupic_mask_ack,
+ .irq_unmask = mn10300_cpupic_unmask,
#ifdef CONFIG_SMP
- .set_affinity = mn10300_cpupic_setaffinity,
+ .irq_set_affinity = mn10300_cpupic_setaffinity,
#endif
};
@@ -271,7 +275,7 @@ void __init init_IRQ(void)
int irq;
for (irq = 0; irq < NR_IRQS; irq++)
- if (irq_desc[irq].chip == &no_irq_chip)
+ if (get_irq_chip(irq) == &no_irq_chip)
/* due to the PIC latching interrupt requests, even
* when the IRQ is disabled, IRQ_PENDING is superfluous
* and we can use handle_level_irq() for edge-triggered
^ permalink raw reply
* [patch 2/7] mn10300: Remove unused mn10300_intc_* functions
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
In-Reply-To: <20110206214441.438777646@linutronix.de>
[-- Attachment #1: mn10300-remove-unused-functions.patch --]
[-- Type: text/plain, Size: 1843 bytes --]
No users.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mn10300/include/asm/intctl-regs.h | 5 -----
arch/mn10300/kernel/irq.c | 25 -------------------------
2 files changed, 30 deletions(-)
Index: linux-next/arch/mn10300/include/asm/intctl-regs.h
===================================================================
--- linux-next.orig/arch/mn10300/include/asm/intctl-regs.h
+++ linux-next/arch/mn10300/include/asm/intctl-regs.h
@@ -60,11 +60,6 @@
#ifndef __ASSEMBLY__
extern void set_intr_level(int irq, u16 level);
-extern void mn10300_intc_set_level(unsigned int irq, unsigned int level);
-extern void mn10300_intc_clear(unsigned int irq);
-extern void mn10300_intc_set(unsigned int irq);
-extern void mn10300_intc_enable(unsigned int irq);
-extern void mn10300_intc_disable(unsigned int irq);
extern void mn10300_set_lateack_irq_type(int irq);
#endif
Index: linux-next/arch/mn10300/kernel/irq.c
===================================================================
--- linux-next.orig/arch/mn10300/kernel/irq.c
+++ linux-next/arch/mn10300/kernel/irq.c
@@ -252,31 +252,6 @@ void set_intr_level(int irq, u16 level)
__mask_and_set_icr(irq, GxICR_ENABLE, level);
}
-void mn10300_intc_set_level(unsigned int irq, unsigned int level)
-{
- set_intr_level(irq, NUM2GxICR_LEVEL(level) & GxICR_LEVEL);
-}
-
-void mn10300_intc_clear(unsigned int irq)
-{
- __mask_and_set_icr(irq, GxICR_LEVEL | GxICR_ENABLE, GxICR_DETECT);
-}
-
-void mn10300_intc_set(unsigned int irq)
-{
- __mask_and_set_icr(irq, 0, GxICR_REQUEST | GxICR_DETECT);
-}
-
-void mn10300_intc_enable(unsigned int irq)
-{
- mn10300_cpupic_unmask(irq);
-}
-
-void mn10300_intc_disable(unsigned int irq)
-{
- mn10300_cpupic_mask(irq);
-}
-
/*
* mark an interrupt to be ACK'd after interrupt handlers have been run rather
* than before
^ permalink raw reply
* [patch 0/7] mn10300: Convert to new irq_chip functions
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
Convert to new irq_chip functions and select GENERIC_HARDIRQS_NO_DEPRECATED
Untested due to lack of hardware and compiler.
Thanks,
tglx
^ permalink raw reply
* [patch 1/7] mn10300: Remove stale irq_chip.end - V2
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
In-Reply-To: <20110206214441.438777646@linutronix.de>
[-- Attachment #1: mn10300-remove-stale-irq_chip-end.patch --]
[-- Type: text/plain, Size: 687 bytes --]
irq_chip.end got obsolete with the remnoval of __do_IRQ().
Might compiles this time, if i had a compiler ...
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mn10300/kernel/mn10300-serial.c | 1 -
1 file changed, 1 deletion(-)
Index: linux-next/arch/mn10300/kernel/mn10300-serial.c
===================================================================
--- linux-next.orig/arch/mn10300/kernel/mn10300-serial.c
+++ linux-next/arch/mn10300/kernel/mn10300-serial.c
@@ -394,7 +394,6 @@ static struct irq_chip mn10300_serial_pi
.mask = mn10300_serial_mask_ack,
.mask_ack = mn10300_serial_mask_ack,
.unmask = mn10300_serial_nop,
- .end = mn10300_serial_nop,
};
^ permalink raw reply
* [PATCH] tinderclient: Remove it (obsoleted by oestats-client)
From: Yuri Bushmelev @ 2011-02-06 21:44 UTC (permalink / raw)
To: openembedded-devel
Tinderclient is unusable now and obsoleted by oestats-client. So we should
remove it from tree.
NOTE for Angstrom and Kaelios maintainers: this patch change your configs.
---
classes/tinderclient.bbclass | 389 ----------------------------------
conf/distro/include/angstrom.inc | 26 ---
conf/distro/include/kaeilos-2010.inc | 22 --
conf/distro/include/kaeilos.inc | 26 ---
conf/tinder.conf | 27 ---
recipes/bitbake/bitbake.inc | 2 +-
6 files changed, 1 insertions(+), 491 deletions(-)
delete mode 100644 classes/tinderclient.bbclass
delete mode 100644 conf/tinder.conf
diff --git a/classes/tinderclient.bbclass b/classes/tinderclient.bbclass
deleted file mode 100644
index 7ccc1f2..0000000
--- a/classes/tinderclient.bbclass
+++ /dev/null
@@ -1,389 +0,0 @@
-def tinder_http_post(d, server, selector, content_type, body):
- import httplib
- # now post it
- for i in range(0,5):
- try:
- proxy = data.getVar('HTTP_PROXY', d, True )
- if (proxy):
- if (proxy.endswith('/')):
- proxy = proxy[:-1]
- if (proxy.startswith('http://')):
- proxy = proxy[7:]
- h = httplib.HTTP(proxy)
- h.putrequest('POST', 'http://%s%s' % (server, selector))
- else:
- h = httplib.HTTP(server)
- h.putrequest('POST', selector)
- h.putheader('content-type', content_type)
- h.putheader('content-length', str(len(body)))
- h.endheaders()
- h.send(body)
- errcode, errmsg, headers = h.getreply()
- #print errcode, errmsg, headers
- return (errcode,errmsg, headers, h.file)
- except Exception, e:
- print "Error sending the report! ", e
- # try again
- pass
-
- # return some garbage
- return (-1, "unknown", "unknown", None)
-
-def tinder_form_data(bound, dict, log):
- output = []
- # for each key in the dictionary
- for name in dict:
- assert dict[name]
- output.append( "--" + bound )
- output.append( 'Content-Disposition: form-data; name="%s"' % name )
- output.append( "" )
- output.append( dict[name] )
- if log:
- output.append( "--" + bound )
- output.append( 'Content-Disposition: form-data; name="log"; filename="log.txt"' )
- output.append( '' )
- output.append( log )
- output.append( '--' + bound + '--' )
- output.append( '' )
-
- return "\r\n".join(output)
-
-def tinder_time_string():
- """
- Return the time as GMT
- """
- return ""
-
-def tinder_format_http_post(d,status,log):
- """
- Format the Tinderbox HTTP post with the data needed
- for the tinderbox to be happy.
- """
-
- import random
-
- # the variables we will need to send on this form post
- variables = {
- "tree" : data.getVar('TINDER_TREE', d, True),
- "machine_name" : data.getVar('TINDER_MACHINE', d, True),
- "os" : os.uname()[0],
- "os_version" : os.uname()[2],
- "compiler" : "gcc",
- "clobber" : data.getVar('TINDER_CLOBBER', d, True) or "0",
- "srcdate" : data.getVar('SRCDATE', d, True),
- "PN" : data.getVar('PN', d, True),
- "PV" : data.getVar('PV', d, True),
- "PR" : data.getVar('PR', d, True),
- "FILE" : data.getVar('FILE', d, True) or "N/A",
- "TARGETARCH" : data.getVar('TARGET_ARCH', d, True),
- "TARGETFPU" : data.getVar('TARGET_FPU', d, True) or "Unknown",
- "TARGETOS" : data.getVar('TARGET_OS', d, True) or "Unknown",
- "MACHINE" : data.getVar('MACHINE', d, True) or "Unknown",
- "DISTRO" : data.getVar('DISTRO', d, True) or "Unknown",
- }
-
- # optionally add the status
- if status:
- variables["status"] = str(status)
-
- # try to load the machine id
- # we only need on build_status.pl but sending it
- # always does not hurt
- try:
- f = file(data.getVar('TMPDIR',d,True)+'/tinder-machine.id', 'r')
- id = f.read()
- variables['machine_id'] = id
- except:
- pass
-
- # the boundary we will need
- boundary = "----------------------------------%d" % int(random.random()*1000000000000)
-
- # now format the body
- body = tinder_form_data( boundary, variables, log )
-
- return ("multipart/form-data; boundary=%s" % boundary),body
-
-
-def tinder_build_start(d):
- """
- Inform the tinderbox that a build is starting. We do this
- by posting our name and tree to the build_start.pl script
- on the server.
- """
- from bb import data
-
- # get the body and type
- content_type, body = tinder_format_http_post(d,None,None)
- server = data.getVar('TINDER_HOST', d, True )
- url = data.getVar('TINDER_URL', d, True )
-
- selector = url + "/xml/build_start.pl"
-
- #print "selector %s and url %s" % (selector, url)
-
- # now post it
- errcode, errmsg, headers, h_file = tinder_http_post(d,server,selector,content_type, body)
- #print errcode, errmsg, headers
- report = h_file.read()
-
- # now let us find the machine id that was assigned to us
- search = "<machine id='"
- report = report[report.find(search)+len(search):]
- report = report[0:report.find("'")]
-
- import bb
- bb.note("Machine ID assigned by tinderbox: %s" % report )
-
- # now we will need to save the machine number
- # we will override any previous numbers
- f = file(data.getVar('TMPDIR', d, True)+"/tinder-machine.id", 'w')
- f.write(report)
-
-
-def tinder_send_http(d, status, _log):
- """
- Send this log as build status
- """
- from bb import data
-
-
- # get the body and type
- server = data.getVar('TINDER_HOST', d, True )
- url = data.getVar('TINDER_URL', d, True )
-
- selector = url + "/xml/build_status.pl"
-
- # now post it - in chunks of 10.000 charachters
- new_log = _log
- while len(new_log) > 0:
- content_type, body = tinder_format_http_post(d,status,new_log[0:18000])
- errcode, errmsg, headers, h_file = tinder_http_post(d,server,selector,content_type, body)
- #print errcode, errmsg, headers
- #print h.file.read()
- new_log = new_log[18000:]
-
-
-def tinder_print_info(d):
- """
- Print the TinderBox Info
- Including informations of the BaseSystem and the Tree
- we use.
- """
-
- from bb import data
- import os
- # get the local vars
-
- time = tinder_time_string()
- ops = os.uname()[0]
- version = os.uname()[2]
- url = data.getVar( 'TINDER_URL' , d, True )
- tree = data.getVar( 'TINDER_TREE', d, True )
- branch = data.getVar( 'TINDER_BRANCH', d, True )
- srcdate = data.getVar( 'SRCDATE', d, True )
- machine = data.getVar( 'MACHINE', d, True )
- distro = data.getVar( 'DISTRO', d, True )
- bbfiles = data.getVar( 'BBFILES', d, True )
- tarch = data.getVar( 'TARGET_ARCH', d, True )
- fpu = data.getVar( 'TARGET_FPU', d, True )
- oerev = data.getVar( 'OE_REVISION', d, True ) or "unknown"
-
- # there is a bug with tipple quoted strings
- # i will work around but will fix the original
- # bug as well
- output = []
- output.append("== Tinderbox Info" )
- output.append("Time: %(time)s" )
- output.append("OS: %(ops)s" )
- output.append("%(version)s" )
- output.append("Compiler: gcc" )
- output.append("Tinderbox Client: 0.1" )
- output.append("Tinderbox Client Last Modified: yesterday" )
- output.append("Tinderbox Protocol: 0.1" )
- output.append("URL: %(url)s" )
- output.append("Tree: %(tree)s" )
- output.append("Config:" )
- output.append("branch = '%(branch)s'" )
- output.append("TARGET_ARCH = '%(tarch)s'" )
- output.append("TARGET_FPU = '%(fpu)s'" )
- output.append("SRCDATE = '%(srcdate)s'" )
- output.append("MACHINE = '%(machine)s'" )
- output.append("DISTRO = '%(distro)s'" )
- output.append("BBFILES = '%(bbfiles)s'" )
- output.append("OEREV = '%(oerev)s'" )
- output.append("== End Tinderbox Client Info" )
-
- # now create the real output
- return "\n".join(output) % vars()
-
-
-def tinder_print_env():
- """
- Print the environment variables of this build
- """
- from bb import data
- import os
-
- time_start = tinder_time_string()
- time_end = tinder_time_string()
-
- # build the environment
- env = ""
- for var in os.environ:
- env += "%s=%s\n" % (var, os.environ[var])
-
- output = []
- output.append( "---> TINDERBOX RUNNING env %(time_start)s" )
- output.append( env )
- output.append( "<--- TINDERBOX FINISHED (SUCCESS) %(time_end)s" )
-
- return "\n".join(output) % vars()
-
-def tinder_tinder_start(d, event):
- """
- PRINT the configuration of this build
- """
-
- time_start = tinder_time_string()
- config = tinder_print_info(d)
- #env = tinder_print_env()
- time_end = tinder_time_string()
- packages = " ".join( event.getPkgs() )
-
- output = []
- output.append( "---> TINDERBOX PRINTING CONFIGURATION %(time_start)s" )
- output.append( config )
- #output.append( env )
- output.append( "<--- TINDERBOX FINISHED PRINTING CONFIGURATION %(time_end)s" )
- output.append( "---> TINDERBOX BUILDING '%(packages)s'" )
- output.append( "<--- TINDERBOX STARTING BUILD NOW" )
-
- output.append( "" )
-
- return "\n".join(output) % vars()
-
-def tinder_do_tinder_report(event):
- """
- Report to the tinderbox:
- On the BuildStart we will inform the box directly
- On the other events we will write to the TINDER_LOG and
- when the Task is finished we will send the report.
-
- The above is not yet fully implemented. Currently we send
- information immediately. The caching/queuing needs to be
- implemented. Also sending more or less information is not
- implemented yet.
-
- We have two temporary files stored in the TMP directory. One file
- contains the assigned machine id for the tinderclient. This id gets
- assigned when we connect the box and start the build process the second
- file is used to workaround an EventHandler limitation. If BitBake is ran
- with the continue option we want the Build to fail even if we get the
- BuildCompleted Event. In this case we have to look up the status and
- send it instead of 100/success.
- """
- from bb.event import getName
- from bb import data, mkdirhier, build
- import os, glob
-
- # variables
- name = getName(event)
- log = ""
- status = 1
- # Check what we need to do Build* shows we start or are done
- if name == "BuildStarted":
- tinder_build_start(event.data)
- log = tinder_tinder_start(event.data,event)
-
- try:
- # truncate the tinder log file
- f = file(data.getVar('TINDER_LOG', event.data, True), 'w')
- f.write("")
- f.close()
- except:
- pass
-
- try:
- # write a status to the file. This is needed for the -k option
- # of BitBake
- g = file(data.getVar('TMPDIR', event.data, True)+"/tinder-status", 'w')
- g.write("")
- g.close()
- except IOError:
- pass
-
- # Append the Task-Log (compile,configure...) to the log file
- # we will send to the server
- if name == "TaskSucceeded" or name == "TaskFailed":
- log_file = glob.glob("%s/log.%s.*" % (data.getVar('T', event.data, True), event.task))
-
- if len(log_file) != 0:
- to_file = data.getVar('TINDER_LOG', event.data, True)
- log += "".join(open(log_file[0], 'r').readlines())
-
- # set the right 'HEADER'/Summary for the TinderBox
- if name == "TaskStarted":
- log += "---> TINDERBOX Task %s started\n" % event.task
- elif name == "TaskSucceeded":
- log += "<--- TINDERBOX Task %s done (SUCCESS)\n" % event.task
- elif name == "TaskFailed":
- log += "<--- TINDERBOX Task %s failed (FAILURE)\n" % event.task
- elif name == "PkgStarted":
- log += "---> TINDERBOX Package %s started\n" % data.getVar('PF', event.data, True)
- elif name == "PkgSucceeded":
- log += "<--- TINDERBOX Package %s done (SUCCESS)\n" % data.getVar('PF', event.data, True)
- elif name == "PkgFailed":
- if not data.getVar('TINDER_AUTOBUILD', event.data, True) == "0":
- build.exec_func('do_clean', event.data)
- log += "<--- TINDERBOX Package %s failed (FAILURE)\n" % data.getVar('PF', event.data, True)
- status = 200
- # remember the failure for the -k case
- h = file(data.getVar('TMPDIR', event.data, True)+"/tinder-status", 'w')
- h.write("200")
- elif name == "BuildCompleted":
- log += "Build Completed\n"
- status = 100
- # Check if we have a old status...
- try:
- h = file(data.getVar('TMPDIR',event.data,True)+'/tinder-status', 'r')
- status = int(h.read())
- except:
- pass
-
- elif name == "MultipleProviders":
- log += "---> TINDERBOX Multiple Providers\n"
- log += "multiple providers are available (%s);\n" % ", ".join(event.getCandidates())
- log += "consider defining PREFERRED_PROVIDER_%s\n" % event.getItem()
- log += "is runtime: %d\n" % event.isRuntime()
- log += "<--- TINDERBOX Multiple Providers\n"
- elif name == "NoProvider":
- log += "Error: No Provider for: %s\n" % event.getItem()
- log += "Error:Was Runtime: %d\n" % event.isRuntime()
- status = 200
- # remember the failure for the -k case
- h = file(data.getVar('TMPDIR', event.data, True)+"/tinder-status", 'w')
- h.write("200")
-
- # now post the log
- if len(log) == 0:
- return
-
- # for now we will use the http post method as it is the only one
- log_post_method = tinder_send_http
- log_post_method(event.data, status, log)
-
-
-# we want to be an event handler
-addhandler tinderclient_eventhandler
-python tinderclient_eventhandler() {
- from bb import note, error, data
- from bb.event import getName
-
- if e.data is None or getName(e) == "MsgNote":
- return
-
- do_tinder_report = data.getVar('TINDER_REPORT', e.data, True)
- if do_tinder_report and do_tinder_report == "1":
- tinder_do_tinder_report(e)
-}
diff --git a/conf/distro/include/angstrom.inc b/conf/distro/include/angstrom.inc
index 6d7770b..5a02723 100644
--- a/conf/distro/include/angstrom.inc
+++ b/conf/distro/include/angstrom.inc
@@ -157,32 +157,6 @@ DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}"
DISTRO_CHECK := "${@bb.data.getVar("DISTRO_VERSION",d,1) or bb.fatal('Remove this line or set a dummy DISTRO_VERSION if you really want to build an unversioned distro')}"
-# Configuration for tinderbox, so people only need:
-# INHERIT += "tinderclient"
-# in their local.conf
-
-#Name of the client
-TINDER_MACHINE = "${MACHINE}-${LIBC}-build-image"
-
-# Which lof file to write to, which tree to report to
-TINDER_LOG = "${TMPDIR}/tinder.log"
-TINDER_TREE = "Angstrom"
-
-# HTTP posting
-TINDER_HOST ?= "ewi546.ewi.utwente.nl"
-TINDER_URL ?= "/tinderbox"
-
-# Which branch do we build
-TINDER_BRANCH = "org.openembedded.dev"
-
-## Clobbing
-## 0 for rebuilding everything from scratch
-## 1 for incremental builds
-TINDER_CLOBBER = "1"
-
-## Do a report at all
-TINDER_REPORT = "1"
-
# Configuration for seppuku autobuilder, people only need to put:
# INHERIT += "seppuku oestats-client"
# SEPPUKU_USER = "your_bugzilla@user.id"
diff --git a/conf/distro/include/kaeilos-2010.inc b/conf/distro/include/kaeilos-2010.inc
index 061039d..fe42858 100644
--- a/conf/distro/include/kaeilos-2010.inc
+++ b/conf/distro/include/kaeilos-2010.inc
@@ -120,28 +120,6 @@ DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}"
# KaeilOS *always* has some form of release config, so error out if someone thinks he knows better
DISTRO_CHECK := "${@bb.data.getVar("DISTRO_VERSION",d,1) or bb.fatal('Remove this line or set a dummy DISTRO_VERSION if you really want to build an unversioned distro')}"
-# Configuration for tinderbox, so people only need:
-# INHERIT += "tinderclient"
-# in their local.conf
-
-#Name of the client
-TINDER_MACHINE = "${MACHINE}-${LIBC}-build-image"
-
-# Which lof file to write to, which tree to report to
-TINDER_LOG = "${TMPDIR}/tinder.log"
-TINDER_TREE = "KaeilOS"
-
-# Which branch do we build
-TINDER_BRANCH = "org.openembedded.dev"
-
-## Clobbing
-## 0 for rebuilding everything from scratch
-## 1 for incremental builds
-TINDER_CLOBBER = "1"
-
-## Do a report at all
-TINDER_REPORT = "1"
-
OESTATS_SERVER ?= "tinderbox.openembedded.org"
# We want images supporting the following features (for task-base)
diff --git a/conf/distro/include/kaeilos.inc b/conf/distro/include/kaeilos.inc
index df4c069..848614f 100644
--- a/conf/distro/include/kaeilos.inc
+++ b/conf/distro/include/kaeilos.inc
@@ -161,32 +161,6 @@ DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}"
DISTRO_CHECK := "${@bb.data.getVar("DISTRO_VERSION",d,1) or bb.fatal('Remove this line or set a dummy DISTRO_VERSION if you really want to build an unversioned distro')}"
-# Configuration for tinderbox, so people only need:
-# INHERIT += "tinderclient"
-# in their local.conf
-
-#Name of the client
-TINDER_MACHINE = "${MACHINE}-${LIBC}-build-image"
-
-# Which lof file to write to, which tree to report to
-TINDER_LOG = "${TMPDIR}/tinder.log"
-TINDER_TREE = "KaeilOS"
-
-# HTTP posting
-#TINDER_HOST ?= "ewi546.ewi.utwente.nl"
-#TINDER_URL ?= "/tinderbox"
-
-# Which branch do we build
-TINDER_BRANCH = "org.openembedded.dev"
-
-## Clobbing
-## 0 for rebuilding everything from scratch
-## 1 for incremental builds
-TINDER_CLOBBER = "1"
-
-## Do a report at all
-TINDER_REPORT = "1"
-
# Configuration for seppuku autobuilder, people only need to put:
# INHERIT += "seppuku oestats-client"
# SEPPUKU_USER = "your_bugzilla@user.id"
diff --git a/conf/tinder.conf b/conf/tinder.conf
deleted file mode 100644
index 614ed89..0000000
--- a/conf/tinder.conf
+++ /dev/null
@@ -1,27 +0,0 @@
-INHERIT += "tinderclient"
-
-
-#Name of the client
-#TINDER_MACHINE = "Test-NameOfClient-build-image"
-
-
-# Which lof file to write to, which tree to report to
-#TINDER_LOG = "${TMPDIR}/tinder.log"
-#TINDER_TREE = "OpenEmbeddedBuilds"
-
-
-# HTTP posting
-#TINDER_HOST = "ewi546.ewi.utwente.nl"
-#TINDER_URL = "/tinderbox"
-
-# Which branch do we build
-#TINDER_BRANCH = "org.openembedded.dev"
-
-# Clobbing
-# 0 for rebuilding everything from scratch
-# 1 for incremental builds
-#TINDER_CLOBBER = "0"
-
-# Do a report at all
-#TINDER_REPORT = "1"
-
diff --git a/recipes/bitbake/bitbake.inc b/recipes/bitbake/bitbake.inc
index 67dc6a5..97983ce 100644
--- a/recipes/bitbake/bitbake.inc
+++ b/recipes/bitbake/bitbake.inc
@@ -12,7 +12,7 @@ SUMMARY = "BitBake build tool"
RDEPENDS_${PN} += "python-shell python-lang python-textutils python-pickle python-crypt python-netclient"
# crypt for md5
-# netclient for tinderclient.bbclass
+# netclient for oestats-client.bbclass (urllib2)
# We don't need a toolchain...
INHIBIT_DEFAULT_DEPS = "1"
--
1.7.2.3
^ permalink raw reply related
* [U-Boot] [GIT PULL] u-boot-mpc83xx - couple of minor fixes
From: Wolfgang Denk @ 2011-02-06 21:42 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20110205172435.405b1f20.kim.phillips@freescale.com>
Dear Kim Phillips,
In message <20110205172435.405b1f20.kim.phillips@freescale.com> you wrote:
> Wolfgang Denk,
>
> Please pull a couple of minor fixes for 83xx:
>
> The following changes since commit f69b980d108b5f15ca7dd3f4284d5a66488c3625:
>
> Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2011-02-04 21:44:46 +0100)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-mpc83xx.git master
>
> Joakim Tjernlund (1):
> mpc83xx: Use correct register to calculate clocks.
>
> Leo Liu (1):
> mpc83xx: fix pcie configuration space read/write
>
> arch/powerpc/cpu/mpc83xx/pcie.c | 19 ++++++++++++++++++-
> arch/powerpc/cpu/mpc83xx/speed.c | 15 ++++++++-------
> include/mpc83xx.h | 7 +++++++
> include/pci.h | 2 ++
> 4 files changed, 35 insertions(+), 8 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is easier to write an incorrect program than understand a correct
one.
^ permalink raw reply
* [U-Boot] Pull request: u-boot-usb
From: Wolfgang Denk @ 2011-02-06 21:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTi=jSxEVBr-32gw9XbfxohYKGaeDhZFniziQa-im@mail.gmail.com>
Dear Remy Bohmer,
In message <AANLkTi=jSxEVBr-32gw9XbfxohYKGaeDhZFniziQa-im@mail.gmail.com> you wrote:
> The following changes since commit f69b980d108b5f15ca7dd3f4284d5a66488c3625:
>
> Merge branch 'master' of git://git.denx.de/u-boot-nand-flash
> (2011-02-04 21:44:46 +0100)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-usb.git master
>
> Alexander Holler (2):
> USB: Fix device stati for removable and powerctrl (typo)
> USB: Change the necessary defines to get debug output
>
> common/usb.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It's not an optical illusion, it just looks like one. -- Phil White
^ permalink raw reply
* [U-Boot] [GIT PULL] lease pull u-boot-mpc85xx.git
From: Wolfgang Denk @ 2011-02-06 21:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <Pine.LNX.4.64.1102041449150.1920@localhost.localdomain>
Dear Kumar Gala,
In message <Pine.LNX.4.64.1102041449150.1920@localhost.localdomain> you wrote:
> Some bug fix and errata fixes.
>
> - k
>
> The following changes since commit 42d44f631c4e8e5359775bdc098f2fffde4e5c05:
>
> Prepare v2011.03-rc1 (2011-02-02 22:37:32 +0100)
>
> are available in the git repository at:
> git://git.denx.de/u-boot-mpc85xx.git master
>
> Kumar Gala (3):
> powerpc/85xx: Enable ESDHC111 Erratum on P2010/P2020 SoCs
> fsl_esdhc: Add the workaround for erratum ESDHC-A001 (enable on P2020)
> powerpc/8xxx: Fix possible compile issue related to P1013
>
> York Sun (5):
> powerpc/85xx: Remove unnecessary polling loop from DDR init
> powerpc/85xx: Enable Errata command on MPC8572DS
> powerpc/85xx: Rename MPC8572 DDR erratum to DDR115
> powerpc/mpc85xx: implement workaround for errata DDR111 and DDR134
> powerpc/85xx: Enable ECC on MPC8572DS
>
> arch/powerpc/cpu/mpc85xx/Makefile | 2 +-
> arch/powerpc/cpu/mpc85xx/cmd_errata.c | 11 +++-
> arch/powerpc/cpu/mpc85xx/ddr-gen3.c | 111 +++++++++++++++++++++++++++-
> arch/powerpc/include/asm/config_mpc85xx.h | 6 ++
> arch/powerpc/include/asm/fsl_ddr_sdram.h | 5 ++
> drivers/mmc/fsl_esdhc.c | 5 ++
> include/configs/MPC8572DS.h | 3 +-
> 7 files changed, 136 insertions(+), 7 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The question of whether a computer can think is no more interesting
than the question of whether a submarine can swim"
- Edsgar W. Dijkstra
^ permalink raw reply
* [Bug 33887] nouveau causes graphic corruption were you cant do anything
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-02-06 21:36 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-33887-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33887
--- Comment #18 from Xavier <shiningxc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2011-02-06 13:36:21 PST ---
(In reply to comment #17)
> I read the mmiotrace.txt file on how to use the kernel functionality.
> Can you tell me what actions exactly would be useful to be traced after the WM
> is started.
>
> It is written :
> "During tracing you can place comments (markers) into the trace by
> $ echo "X is up" > /sys/kernel/debug/tracing/trace_marker
> This makes it easier to see which part of the (huge) trace corresponds to
> which action. It is recommended to place descriptive markers about what you
> do."
> But what actions exactly to do during the trace process ?
>
> And :
> "Please, pack into a compressed archive the trace file and a free description
> about what you do during the trace."
> Again what is useful to do ?
>
AFAIK with nouveau, you get corruption just by starting X.
So I think you just need to start X with the blob, mark X is up in the trace,
and stop.
> Can you also precise to me the format of the name of the archive file.
> "The name of the archive file should contain the PCI id and GPU family, or the
> commercial name of your card."
> Can you give an example of name please ?
>
> Again :
> "If you are doing a trace for a driver project, e.g. Nouveau, you should also
> do the following before sending your results:
> $ lspci -vvv > lspci.txt
> $ dmesg > dmesg.txt
> $ tar zcf pciid-nick-mmiotrace.tar.gz mydump.txt lspci.txt dmesg.txt
> and then send the .tar.gz file. The trace compresses considerably. Replace
> "pciid" and "nick" with the PCI ID or model name of your piece of hardware
> under investigation and your nickname."
> I would like an example of name of the tarball file.
$ lspci -n -d 10de:
01:00.0 0300: 10de:0407 (rev a1)
-> the pci id of my card is 0407 (10de is vendor id, nvidia)
$ dmesg | grep generation
[11562.063550] [drm] nouveau 0000:01:00.0: Detected an NV50 generation card
(0x084700a2)
-> generation is nv50, codename nv84.
So in my case I would just call it nv84-0407-shining-mmiotrace.tar.gz
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in rfc4106_set_hash_subkey().
From: Jesper Juhl @ 2011-02-06 21:33 UTC (permalink / raw)
To: Herbert Xu
Cc: Struk, Tadeusz, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, x86@kernel.org, H. Peter Anvin,
Ingo Molnar, Thomas Gleixner, David S. Miller, Huang, Ying,
Hoban, Adrian, Paoloni, Gabriele, O Mahony, Aidan
In-Reply-To: <20110206204829.GA12652@gondor.apana.org.au>
On Mon, 7 Feb 2011, Herbert Xu wrote:
> On Sun, Feb 06, 2011 at 09:34:33PM +0100, Jesper Juhl wrote:
> > On Mon, 7 Feb 2011, Herbert Xu wrote:
> >
> > > On Sun, Feb 06, 2011 at 08:43:22PM +0100, Jesper Juhl wrote:
> > > >
> > > > Herbert: If Tadeusz agrees, could you please replace the patch you merged
> > > > with the one above?
> > >
> > > Please send an incremental patch.
> > >
> > Sure thing. What would you like it based on exactly?
>
> The current cryptodev-2.6 tree should do.
>
Here goes.
Fix up previous patch that attempted to fix a mem leak in
rfc4106_set_hash_subkey. The previous patch was flawed in that the 'goto
out' would still leak.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
aesni-intel_glue.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index e013552..4a8c015 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -874,7 +874,7 @@ rfc4106_set_hash_subkey(u8 *hash_subkey, const u8 *key, unsigned int key_len)
ret = crypto_ablkcipher_setkey(ctr_tfm, key, key_len);
if (ret)
- goto out;
+ goto out_free_ablkcipher;
req = ablkcipher_request_alloc(ctr_tfm, GFP_KERNEL);
if (!req) {
@@ -916,7 +916,6 @@ out_free_request:
kfree(req_data);
out_free_ablkcipher:
crypto_free_ablkcipher(ctr_tfm);
-out:
return ret;
}
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* Re: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in rfc4106_set_hash_subkey().
From: Jesper Juhl @ 2011-02-06 21:33 UTC (permalink / raw)
To: Herbert Xu
Cc: Struk, Tadeusz, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, x86@kernel.org, H. Peter Anvin,
Ingo Molnar, Thomas Gleixner, David S. Miller, Huang, Ying,
Hoban, Adrian, Paoloni, Gabriele, O Mahony, Aidan
In-Reply-To: <20110206204829.GA12652@gondor.apana.org.au>
On Mon, 7 Feb 2011, Herbert Xu wrote:
> On Sun, Feb 06, 2011 at 09:34:33PM +0100, Jesper Juhl wrote:
> > On Mon, 7 Feb 2011, Herbert Xu wrote:
> >
> > > On Sun, Feb 06, 2011 at 08:43:22PM +0100, Jesper Juhl wrote:
> > > >
> > > > Herbert: If Tadeusz agrees, could you please replace the patch you merged
> > > > with the one above?
> > >
> > > Please send an incremental patch.
> > >
> > Sure thing. What would you like it based on exactly?
>
> The current cryptodev-2.6 tree should do.
>
Here goes.
Fix up previous patch that attempted to fix a mem leak in
rfc4106_set_hash_subkey. The previous patch was flawed in that the 'goto
out' would still leak.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
aesni-intel_glue.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index e013552..4a8c015 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -874,7 +874,7 @@ rfc4106_set_hash_subkey(u8 *hash_subkey, const u8 *key, unsigned int key_len)
ret = crypto_ablkcipher_setkey(ctr_tfm, key, key_len);
if (ret)
- goto out;
+ goto out_free_ablkcipher;
req = ablkcipher_request_alloc(ctr_tfm, GFP_KERNEL);
if (!req) {
@@ -916,7 +916,6 @@ out_free_request:
kfree(req_data);
out_free_ablkcipher:
crypto_free_ablkcipher(ctr_tfm);
-out:
return ret;
}
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* [U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment
From: Grant Erickson @ 2011-02-06 21:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <C974475E.23E4D%gerickson@nuovations.com>
On 2/6/11 12:41 PM, Grant Erickson wrote:
> I recently updated my TI AM37x EVM from U-Boot 2010.09 to 2010.12 and noticed
> that, in doing so, saveenv / env save no longer seems to work. The following
> example demonstrates [ELIDED]:
I subsequently found the following patch and commit:
http://www.mail-archive.com/u-boot at lists.denx.de/msg46834.html
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=920a5dd2325438a82b6ac8102c5a
5e0c43276fd;hp=42d44f631c4e8e5359775bdc098f2fffde4e5c05
However, it's not clear how this patch can reasonably work outside of random
chance:
// Allocate a new environment on the stack. The environment structure is
// whatever random data is already on the stack.
env_t env_new;
...
// At this point, the data field will be initialized; however, crc and
// flags are still random data.
res = (char *)&env_new.data;
len = hexport_r(&env_htab, '\0', &res, ENV_SIZE);
// The crc field is now set.
env_new.crc = crc32(0, env_new.data, ENV_SIZE);
// Preincrement random data.
++env_new.flags; /* increase the serial */
Unfortunately, preincrementing random data won't replicate the behavior of
2010.09, where the flags field was referenced through a global env_ptr such
that flag manipulation was handled (more) coherently as the environment was
read and written.
Best,
Grant
^ permalink raw reply
* [Bug 33792] [r600g] Evergreen vertex shaders transform vertices incorrectly in wine programs
From: bugzilla-daemon @ 2011-02-06 21:26 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-33792-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33792
--- Comment #11 from Rubén Fernández <rubenf3000@gmail.com> 2011-02-06 13:26:53 PST ---
Aside from Portal and Tales of Monkey Island, all the other games work
perfectly now, thanks to Henri's patch
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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.