* Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
From: Avi Kivity @ 2011-10-24 15:30 UTC (permalink / raw)
To: Dave Anderson
Cc: Jan Kiszka, Richard W.M. Jones, qemu-devel, Luiz Capitulino,
KAMEZAWA Hiroyuki
In-Reply-To: <54c9dc1d-3104-4f42-9a20-d7f4da516bdc@zmail05.collab.prod.int.phx2.redhat.com>
On 10/24/2011 05:25 PM, Dave Anderson wrote:
>
> ----- Original Message -----
> > On 10/24/2011 04:25 PM, Dave Anderson wrote:
> > > > The question is that: 'virsh dump' can not be used when host pci device
> > > > is used by guest. We are discussing how to fix the problem. We have determined
> > > > that introduce a new monitor command dump. Jan suggested that the core file's
> > > > format is gdb standard core format. Does crash support such format? If no,
> > > > is it possible to support such format?
> > >
> > > If you are talking about an ELF core dump of the user-space qemu-kvm process
> > > running on the host, then it's certainly not supported.
> >
> > No, an ELF image of the guest's physical memory.
>
> Well then that should be pretty straight forward to support. Depending upon
> how similar it would be to the "standard" kdump ELF format, the only other
> issue is how to determine the physical base address at which the kernel is
> loaded, in order to be able to translate the mapped kernel-text/static-data
> virtual region of the x86_64 arch (the __START_KERNEL_map region).
>
I guess an elf note would work for that?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: NFS4 BAD_STATEID loop (kernel 3.0.4)
From: Trond Myklebust @ 2011-10-24 15:31 UTC (permalink / raw)
To: David Flynn; +Cc: linux-nfs, Chuck Lever
In-Reply-To: <20111024145027.GF32587@rd.bbc.co.uk>
On Mon, 2011-10-24 at 14:50 +0000, David Flynn wrote:
> No. Time Source Destination Protocol Size Info
> 39 15:33:59.077143 172.29.190.28 172.29.120.140 NFS 370 V4 COMPOUND Call (Reply In 40) <EMPTY> PUTFH;WRITE;GETATTR
>
> Frame 39: 370 bytes on wire (2960 bits), 370 bytes captured (2960 bits)
> Ethernet II, Src: ChelsioC_07:49:6f (00:07:43:07:49:6f), Dst: All-HSRP-routers_be (00:00:0c:07:ac:be)
> Internet Protocol, Src: 172.29.190.28 (172.29.190.28), Dst: 172.29.120.140 (172.29.120.140)
> Transmission Control Protocol, Src Port: omginitialrefs (900), Dst Port: nfs (2049), Seq: 40433, Ack: 7449, Len: 304
> Remote Procedure Call, Type:Call XID:0x43ce4e16
> Network File System
> [Program Version: 4]
> [V4 Procedure: COMPOUND (1)]
> Tag: <EMPTY>
> length: 0
> contents: <EMPTY>
> minorversion: 0
> Operations (count: 3)
> Opcode: PUTFH (22)
> filehandle
> length: 36
> [hash (CRC-32): 0x6e4b15f3]
> decode type as: unknown
> filehandle: 7df3a75d5e1cd908000ab44c5b000000efc80200000a0300...
> Opcode: WRITE (38)
> stateid
Do you have an example of the stateid argument's value? Does it change
at all between separate WRITE attempts?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* What's cooking in git.git (Oct 2011, #09; Sun, 23)
From: Junio C Hamano @ 2011-10-24 15:31 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
It probably is a good point to stop taking new topics and start
switching our focus to fixing bugs in the topics already in 'master'.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo, html and man:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint, master, html and man:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches but not todo, html or man:
https://github.com/gitster/git
By the way, I am planning to stop pushing the generated documentation
branches to the above repositories in the near term, as they are not
sources. The only reason the source repository at k.org has hosted these
branches was because it was the only repository over there that was
writable by me; it was an ugly historical and administrative workaround
and not a demonstration of the best practice.
They are pushed to their own separate repositories instead:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* nd/pretty-commit-log-message (2011-10-23) 2 commits
- pretty.c: use original commit message if reencoding fails
- pretty.c: free get_header() return value
--------------------------------------------------
[Graduated to "master"]
* cn/doc-config-bare-subsection (2011-10-16) 1 commit
(merged to 'next' on 2011-10-17 at a6412d4)
+ Documentation: update [section.subsection] to reflect what git does
* jc/broken-ref-dwim-fix (2011-10-19) 3 commits
(merged to 'next' on 2011-10-19 at 40cad95)
+ resolve_ref(): report breakage to the caller without warning
+ resolve_ref(): expose REF_ISBROKEN flag
+ refs.c: move dwim_ref()/dwim_log() from sha1_name.c
(this branch is tangled with jc/check-ref-format-fixup.)
This only takes good bits from the failed jc/check-ref-format-fixup topic
and implements saner workaround for the recent breakage on the 'master'.
* jc/maint-remove-renamed-ref (2011-10-12) 1 commit
(merged to 'next' on 2011-10-12 at 819c3e4)
+ branch -m/-M: remove undocumented RENAMED-REF
* jc/make-tags (2011-10-18) 1 commit
(merged to 'next' on 2011-10-19 at b0b91bf)
+ Makefile: ask "ls-files" to list source files if available
* jc/match-refs-clarify (2011-09-12) 2 commits
(merged to 'next' on 2011-10-19 at b295e1e)
+ rename "match_refs()" to "match_push_refs()"
+ send-pack: typofix error message
* jc/unseekable-bundle (2011-10-13) 2 commits
(merged to 'next' on 2011-10-19 at 2978ee0)
+ bundle: add parse_bundle_header() helper function
+ bundle: allowing to read from an unseekable fd
* jk/daemon-msgs (2011-10-15) 1 commit
(merged to 'next' on 2011-10-15 at 415cf53)
+ daemon: give friendlier error messages to clients
(this branch is used by cb/daemon-permission-errors.)
* jk/maint-pack-objects-compete-with-delete (2011-10-14) 2 commits
(merged to 'next' on 2011-10-15 at 49479e4)
+ downgrade "packfile cannot be accessed" errors to warnings
+ pack-objects: protect against disappearing packs
* mh/ref-api (2011-10-16) 7 commits
(merged to 'next' on 2011-10-17 at 219000f)
+ clear_ref_cache(): inline function
+ write_ref_sha1(): only invalidate the loose ref cache
+ clear_ref_cache(): extract two new functions
+ clear_ref_cache(): rename parameter
+ invalidate_ref_cache(): expose this function in the refs API
+ invalidate_ref_cache(): take the submodule as parameter
+ invalidate_ref_cache(): rename function from invalidate_cached_refs()
(this branch is used by mh/ref-api-2 and mh/ref-api-3.)
* ph/transport-with-gitfile (2011-10-11) 5 commits
(merged to 'next' on 2011-10-12 at 6d58417)
+ Fix is_gitfile() for files too small or larger than PATH_MAX to be a gitfile
(merged to 'next' on 2011-10-06 at 891b8b6)
+ Add test showing git-fetch groks gitfiles
+ Teach transport about the gitfile mechanism
+ Learn to handle gitfiles in enter_repo
+ enter_repo: do not modify input
* po/insn-editor (2011-10-17) 1 commit
(merged to 'next' on 2011-10-19 at cbf5e0b)
+ "rebase -i": support special-purpose editor to edit insn sheet
* pw/p4-update (2011-10-17) 6 commits
(merged to 'next' on 2011-10-17 at f69f6cc)
+ git-p4: handle files with shell metacharacters
+ git-p4: keyword flattening fixes
+ git-p4: stop ignoring apple filetype
+ git-p4: recognize all p4 filetypes
+ git-p4: handle utf16 filetype properly
+ git-p4 tests: refactor and cleanup
* sc/difftool-skip (2011-10-14) 2 commits
(merged to 'next' on 2011-10-14 at b91c581)
+ t7800: avoid arithmetic expansion notation
(merged to 'next' on 2011-10-11 at 38d7e84)
+ git-difftool: allow skipping file by typing 'n' at prompt
* ss/inet-ntop (2011-10-18) 1 commit
(merged to 'next' on 2011-10-19 at 85469f6)
+ inet_ntop.c: Work around GCC 4.6's detection of uninitialized variables
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-10-13) 4 commits
- submodule.c: make two functions static
- allow multiple calls to submodule merge search for the same path
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
The fix-up at the tip queued on fg/submodule-auto-push topic has been
moved to this topic.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) would help.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload.
* jc/verbose-checkout (2011-10-16) 2 commits
- checkout -v: give full status output after switching branches
- checkout: move the local changes report to the end
This is just to leave a record that the reason why we do not do this not
because we are incapable of coding this, but because it is not a good idea
to do this. I suspect people who are new to git that might think they need
it would soon realize the don't.
Will keep in 'pu' as a showcase for a while and then will drop.
--------------------------------------------------
[Cooking]
* tc/submodule-clone-name-detection (2011-10-21) 2 commits
(merged to 'next' on 2011-10-23 at c18af03)
+ submodule::module_clone(): silence die() message from module_name()
+ submodule: whitespace fix
"git submodule clone" used to show unnecessary error message when
submodule mapping from name to path is not found in .gitmodules file.
Will merge to 'master'.
* jm/maint-gitweb-filter-forks-fix (2011-10-21) 1 commit
(merged to 'next' on 2011-10-21 at debedcd)
+ gitweb: fix regression when filtering out forks
Will merge to 'master' shortly.
* lh/gitweb-site-html-head (2011-10-21) 1 commit
(merged to 'next' on 2011-10-23 at 65075df)
+ gitweb: provide a way to customize html headers
Will merge to 'master' shortly.
* mh/ref-api-3 (2011-10-19) 11 commits
(merged to 'next' on 2011-10-23 at 92e2d35)
+ is_refname_available(): reimplement using do_for_each_ref_in_array()
+ names_conflict(): simplify implementation
+ names_conflict(): new function, extracted from is_refname_available()
+ repack_without_ref(): reimplement using do_for_each_ref_in_array()
+ do_for_each_ref_in_array(): new function
+ do_for_each_ref(): correctly terminate while processesing extra_refs
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ parse_ref_line(): add a check that the refname is properly formatted
+ repack_without_ref(): remove temporary
+ Rename another local variable name -> refname
(this branch uses mh/ref-api-2.)
* mm/mediawiki-author-fix (2011-10-20) 1 commit
(merged to 'next' on 2011-10-23 at 9f85b67)
+ git-remote-mediawiki: don't include HTTP login/password in author
Will merge to 'master' shortly.
* rr/revert-cherry-pick (2011-10-23) 5 commits
- revert: simplify communicating command-line arguments
- revert: allow mixed pick and revert instructions
- revert: make commit subjects in insn sheet optional
- revert: simplify getting commit subject in format_todo()
- revert: free msg in format_todo()
The internals of "git revert/cherry-pick" has been further refactored to
serve as the basis for the sequencer.
Will merge to 'next'.
* jn/libperl-git-config (2011-10-21) 2 commits
(merged to 'next' on 2011-10-21 at 76e2d4b)
+ Add simple test for Git::config_path() in t/t9700-perl-git.sh
+ libperl-git: refactor Git::config_*
Will merge to 'master' shortly.
* jc/check-ref-format-fixup (2011-10-19) 2 commits
(merged to 'next' on 2011-10-19 at 98981be)
+ Revert "Restrict ref-like names immediately below $GIT_DIR"
(merged to 'next' on 2011-10-15 at 8e89bc5)
+ Restrict ref-like names immediately below $GIT_DIR
This became a no-op except for the bottom one which is part of the other
topic now.
Will discard once the other topic graduates to 'master'.
* cb/daemon-permission-errors (2011-10-17) 2 commits
- daemon: report permission denied error to clients
- daemon: add tests
The tip commit might be loosening things a bit too much.
Will keep in 'pu' until hearing a convincing argument for the patch.
* kk/gitweb-side-by-side-diff (2011-10-17) 2 commits
- gitweb: add a feature to show side-by-side diff
- gitweb: change format_diff_line() to remove leading SP from $diff_class
Fun.
Will keep in 'pu' until the planned re-roll comes.
* mh/ref-api-2 (2011-10-17) 14 commits
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is used by mh/ref-api-3.)
It is either merge this quickly to 'master' and hope there won't be any
more unexpected breakage that forces us to delay the release, or hold it
on 'next' until the next cycle. I am inclined to do the former, but not
quite ready to commit to it yet.
* dm/pack-objects-update (2011-10-20) 4 commits
- pack-objects: don't traverse objects unnecessarily
- pack-objects: rewrite add_descendants_to_write_order() iteratively
- pack-objects: use unsigned int for counter and offset values
- pack-objects: mark add_to_write_order() as inline
Need to re-read this before deciding what to do; it came a bit too late in
the cycle for a series that touches a seriously important part of the
system.
* jk/git-tricks (2011-10-21) 3 commits
(merged to 'next' on 2011-10-23 at 7c9bf71)
+ completion: match ctags symbol names in grep patterns
+ contrib: add git-jump script
+ contrib: add diff highlight script
* jc/signed-commit (2011-10-21) 7 commits
(merged to 'next' on 2011-10-23 at 03eec25)
+ pretty: %G[?GS] placeholders
+ parse_signed_commit: really use the entire commit log message
+ test "commit -S" and "log --show-signature"
+ t7004: extract generic "GPG testing" bits
+ log: --show-signature
+ commit: teach --gpg-sign option
+ Split GPG interface into its own helper library
This is to replace the earlier "signed push" experiments.
Will keep in 'next' during this cycle.
* sg/complete-refs (2011-10-21) 9 commits
- completion: remove broken dead code from __git_heads() and __git_tags()
- completion: fast initial completion for config 'remote.*.fetch' value
- completion: improve ls-remote output filtering in __git_refs_remotes()
- completion: query only refs/heads/ in __git_refs_remotes()
- completion: support full refs from remote repositories
- completion: improve ls-remote output filtering in __git_refs()
- completion: make refs completion consistent for local and remote repos
- completion: optimize refs completion
- completion: document __gitcomp()
Will merge to 'next' but won't merge further until an Ack or two from
people who have worked on the completion in the past comes.
* cn/fetch-prune (2011-10-15) 5 commits
(merged to 'next' on 2011-10-16 at 02a449e)
+ fetch: treat --tags like refs/tags/*:refs/tags/* when pruning
+ fetch: honor the user-provided refspecs when pruning refs
+ remote: separate out the remote_find_tracking logic into query_refspecs
+ t5510: add tests for fetch --prune
+ fetch: free all the additional refspecs
"git fetch --prune" used to prune remote tracking branches by comparing
what was actually fetched and what was configured to be fetched, which was
wrong.
Will merge to 'master' shortly.
* jc/request-pull-show-head-4 (2011-10-15) 11 commits
(merged to 'next' on 2011-10-15 at 7e340ff)
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
(merged to 'next' on 2011-10-10 at 092175e)
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements.
Will keep in 'next' during this cycle.
^ permalink raw reply
* [U-Boot] [PATCH] mx31pdk: Add MC13783 PMIC support
From: Fabio Estevam @ 2011-10-24 15:32 UTC (permalink / raw)
To: u-boot
Add MC13783 PMIC support.
Tested by using the 'date' command, which reads the MC13783 RTC registers:
MX31PDK U-Boot > date
Date: 1970-01-01 (Thursday) Time: 2:22:35
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
board/freescale/mx31pdk/mx31pdk.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mx31pdk/mx31pdk.c b/board/freescale/mx31pdk/mx31pdk.c
index 0e7e0ce..9f8bc53 100644
--- a/board/freescale/mx31pdk/mx31pdk.c
+++ b/board/freescale/mx31pdk/mx31pdk.c
@@ -30,6 +30,8 @@
#include <asm/arch/imx-regs.h>
#include <asm/arch/sys_proto.h>
#include <watchdog.h>
+#include <pmic.h>
+#include <fsl_pmic.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -79,6 +81,16 @@ int board_init(void)
int board_late_init(void)
{
+ u32 val;
+ struct pmic *p;
+
+ pmic_init();
+ p = get_pmic();
+
+ /* Enable RTC battery */
+ pmic_reg_read(p, REG_POWER_CTL0, &val);
+ pmic_reg_write(p, REG_POWER_CTL0, val | COINCHEN);
+ pmic_reg_write(p, REG_INT_STATUS1, RTCRSTI);
#ifdef CONFIG_HW_WATCHDOG
mxc_hw_watchdog_enable();
#endif
--
1.6.0.4
^ permalink raw reply related
* [Buildroot] [RFC] Slides "Using Buildroot for real projects"
From: Thomas Petazzoni @ 2011-10-24 15:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111023123755.GA2455@tarshish>
Le Sun, 23 Oct 2011 14:37:55 +0200,
Baruch Siach <baruch@tkos.co.il> a ?crit :
> 1. Slide 23: missing -e in the 'echo' command
>
> $ echo "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
> /dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0
>
> $ echo -e "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
> /dev/mtdblock7 /applog jffs2 defaults 0 0
-e is not needed with sh:
$ echo "bla\nbli"
bla
bli
$ echo -e "bla\nbli"
-e bla
bli
> 2. Slides 24-27: header should be "Project-specific packages (x/5)", instead
> of "... (x/4)". (Can't TeX do this automatically somehow?)
Fixed. I don't know if TeX can do this automatically. Maybe.
Thanks for the comments. I also fixed the various comments raised by
Thomas. Thanks again!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2011-10-24 15:32 UTC (permalink / raw)
To: git
Welcome to git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites as well:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
and some people seem to prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop your
bug report with just "git does not work". "I tried to do X but it did not
work" is not much better, neither is "I tried to do X and git did Y, which
is broken". It often is that what you expect is _not_ what other people
expect, and chances are that what you expect is very different from what
people who have worked on git have expected (otherwise, the behavior
would have been changed to match that expectation long time ago).
Please remember to always state
- what you wanted to do;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen;
- what you expected to see; and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git
https://github.com/git/git
https://code.google.com/p/git-core/
Impatient people might have better luck with the latter two (there are a
few other mirrors I push into at sourceforge and github as well).
Their gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
There are three branches in git.git repository that are not about the
source tree of git: "html", "man", and "todo".
The "html" and "man" are preformatted documentation from the tip of
the "master" branch; the tip of "html" is visible at:
http://www.kernel.org/pub/software/scm/git/docs/
http://git-core.googlecode.com/git-history/html/git.html
The above URL is the top-level documentation page, and it may have
links to documentation of older releases.
The "todo" branch was originally meant to contain a TODO list for me,
but is mostly used to keep some helper scripts I use to maintain git.
For example, the script that was used to maintain the two documentation
branches are found there as dodoc.sh, which may be a good demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits. The last such release was 1.7.7 done on
Sept 30, 2011. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.7.1. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid production ready, but is expected to work more or
less without major breakage. The "next" branch is where new and exciting
things take place. A topic that is in "next" is expected to be polished to
perfection before it is merged to "master" (that's why "master" can be
expected to stay more stable than any released version).
The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre on pack issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
cvsserver and cvsimport.
- Paul Mackerras on gitk.
- Eric Wong, David D. Kilzer and Sam Vilain on git-svn.
- Simon Hausmann and Pete Wyckoff on git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
gitweb.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
documentation (and countless others for proofreading and fixing).
- Alexandre Julliard on Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool
(and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
for their effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability;
especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
Brandon Casey, Jeff King, Alex Riesen and countless others.
* This document
The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.
^ permalink raw reply
* Re: Eclipse Plugin: ADT Version too old
From: Joshua Lock @ 2011-10-24 15:33 UTC (permalink / raw)
To: yocto
In-Reply-To: <4EA52BEF.8000100@communistcode.co.uk>
On 24/10/11 02:12, Jack Mitchell wrote:
> On 24/10/2011 10:03, Jack Mitchell wrote:
>> I am trying to use the new eclipse plugin, which I have had working
>> fine for the past couple of weeks until I switched from the master
>> branch to edison.
>>
>> I performed a fresh build using the stable edison branch, installed
>> the new 1.1 eclipse plugin and now whenever I try to setup the Yocto
>> eclipse environment I receive the following error:
>>
>> Yocto Preferences Configuration Error!
>> OECORE related items are not found in envrionement setup files.
>> The ADT version you're using is too old.
>> Please upgrade to our latest ADT Version!
>>
>> This pops up in a message box, not the eclipse console. I have
>> followed the ADT Setup guide to the letter and it's not playing ball -
>> could someone confirm this as working or point me towards a reason why
>> I may be getting this error?
>>
>> Cheers,
>> Jack.
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> This is a pastebin of my current environment setup file:
>
> http://pastebin.com/4vnWPAD2
>
I'm not ADT expert but I expect the problem is this line:
export OECORE_DISTRO_VERSION="1.1+snapshot-20111021"
By switching to the edison branch you'll now have a DISTRO_VERSION of
"1.1", without the snapshot and date - hence version mismatch.
I'm not sure if you need to change the plugin or just build a new
meta-ide-support, though.
Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
^ permalink raw reply
* lib/md5.o build problem
From: Antony Pavlov @ 2011-10-24 15:33 UTC (permalink / raw)
To: barebox
Hi!
I can't build barebox with md5sum command.
Here is the log:
$ date
Mon Oct 24 19:29:51 MSD 2011
$ git clone --branch next git://git.pengutronix.de/git/barebox.git
barebox.git.next
$ cd barebox.git.next
$ make ARCH=arm versatilepb_defconfig
$ sed "s/# CONFIG_CMD_MD5SUM.*/CONFIG_CMD_MD5SUM=y/" -i .config
$ make ARCH=arm oldconfig
$ make -j 2 ARCH=arm CROSS_COMPILE=arm-realview-linux-gnueabi-
...
CC lib/show_progress.o
CC lib/decompress_unlzo.o
make[1]: *** No rule to make target `lib/md5.o', needed by
`lib/built-in.o'. Stop.
make[1]: *** Waiting for unfinished jobs....
CC lib/process_escape_sequence.o
make: *** [lib] Error 2
make: *** Waiting for unfinished jobs....
LD fs/built-in.o
--
Best regards,
Antony Pavlov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: ALSA PulseAudio plugin: snd_pcm_rewindable() returns >0, but snd_pcm_rewind() is broken
From: Pierre-Louis Bossart @ 2011-10-24 15:34 UTC (permalink / raw)
To: 'Nikolay Nikolov', alsa-devel
In-Reply-To: <4EA567EA.1020603@gmail.com>
> I'm using the max buffer size, which is 1048576 frames (4MB buffer,
> 16-bit stereo). The buffer is almost full when I try to rewind. I first
> call snd_pcm_rewindable() and it returns a greater than zero value.
> Then
> I call snd_pcm_rewind() with this value and it returns success, i.e. a
> positive value of frames actually rewound. I then call snd_pcm_writei
> with the number of frames rewound and I get a weird pause (several
> seconds) in the audio on the next poll. Audio then continues from the
> middle; the beginning of the audio that was rewritten immediately after
> rewind() has been dropped.
You want to avoid rewinding completely. Your audio hardware might have
prefetched data with the DMA subsystem. Rewinding completely might result in
an inconsistent configuration and possibly underflows. If you look at the
PulseAudio code, we've introduced some thresholds beyond which we don't
rewind (128 bytes or 1ms off the top of my head).
You might argue that snd_pcm_rewindable is broken, but it's somewhat
difficult to fix as the amount of prefetched data isn't modeled in the
driver and it's very much hardware-specific. Using a less aggressive
approach works fine on most hardware.
-Pierre
^ permalink raw reply
* Re: [Qemu-devel] KVM call agenda for October 25
From: Luiz Capitulino @ 2011-10-24 15:34 UTC (permalink / raw)
To: Peter Maydell; +Cc: Paolo Bonzini, qemu-devel, kvm
In-Reply-To: <CAFEAcA_5-ZsJZX3fYDq8bLy8MRPuqqO5CCz=Q7pZurr_5O6ghg@mail.gmail.com>
On Mon, 24 Oct 2011 13:02:05 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:
> On 24 October 2011 12:35, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 10/24/2011 01:04 PM, Juan Quintela wrote:
> >> Please send in any agenda items you are interested in covering.
> >
> > - What's left to merge for 1.0.
>
> Things on my list, FWIW:
> * current target-arm pullreq
> * PL041 support (needs another patch round to fix a minor bug
> Andrzej spotted)
> * cpu_single_env must be thread-local
I submitted today the second round of QAPI conversions, which converts all
existing QMP query commands to the QAPI (plus some fixes).
I expect that to make 1.0.
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA58368.6050704@stericsson.com>
Ulf Hansson wrote:
> Linus Walleij wrote:
>> On Mon, Oct 24, 2011 at 1:48 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>>> [Russell]
>>>> The MCIPWR signal controls the external power switch. This is the only
>>>> signal for it. This is the only connection for it. There is no other
>>>> control form for this power switch.
>>>>
>>> Then we are only left to use the variant struct I believe. In principle, a
>>> flag in the variant struct, could indicate whether it is OK to disable the
>>> vcore regulator and thus clear the MCIPWR when doing runtime_suspend.
>> Yep I think the best could be to add some variant named
>> bool external_card_power; and then document in the kerneldoc that this
>> means the driver can clear MMCIPWR without risk of cutting the power
>> to the card.
>>
>> This should be true for Ux500, U300 and Nomadik (just checked the designs -
>> they all have external regulators).
>>
>
> Could we assume that all boards which utilizes the ARM PL180 are using
> the MMCIPWR register to control power the card? Or should we add a new
> amba mmci platform member so this is configurable for each board?
>
> An option could also be if we might want to simplify code to just skip
> the entire runtime_suspend|idle|resume function (ie stubb it or
> something) for these kind of boards?
>
> What do you prefer?
By the way, there is also another option. In the runtime_suspend
function for ARM PL180 block we can use mmc_power_save_host (and then
also disable vcore etc) and vice verse in runtime_resume with
mmc_power_restore_host.
Of course, these kind of operations takes quite some time to execute and
therefore we use a much bigger timeout than 50 ms (for example 10 s
instead) for ARM PL180.
Just an idea...
>
>> So the state save/restore and amba_vcore_disable(adev); should be done
>> only for those variants.
>>
>> However this:
>>
>> clk_disable(host->clk);
>>
>> We ought to be able to do for *all* variants, provided we can create
>> pm_runtime_get/put and delay properly to cover all bus traffic
>> (looks like the patch already does that), plus all the time the card is
>> signalling busy. The best I can think of is to just return -EBUSY to runtime
>> PM like this:
>>
>> if ((readl(base + MMCISTATUS) & (MCI_CMDACTIVE | MCI_TXACTIVE| MCI_RXACTIVE))
>> return -EBUSY;
>>
>> Yours,
>> Linus Walleij
>>
>
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 35/35] scsi-disk: add scsi-block for device passthrough
From: Kevin Wolf @ 2011-10-24 15:38 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <4EA5841A.2080406@redhat.com>
Am 24.10.2011 17:28, schrieb Paolo Bonzini:
> On 10/24/2011 05:28 PM, Kevin Wolf wrote:
>>> scsi-block is a new device that supports device passthrough of Linux
>>>> block devices (i.e. /dev/sda, not /dev/sg0). It uses SG_IO for commands
>>>> other than I/O commands, and regular AIO read/writes for I/O commands.
>>>> Besides being simpler to configure (no mapping required to scsi-generic
>>>> device names), this removes the need for a large bounce buffer and,
>>>> in the future, will get scatter/gather support for free from scsi-disk.
>>>>
>>>> Signed-off-by: Paolo Bonzini<pbonzini@redhat.com>
>>
>> This doesn't seem to use much of scsi-disk, so what about exporting
>> &scsi_disk_reqops and adding a separate file scsi-block.c? Would make
>> things a bit more symmetrical between scsi-disk and scsi-generic.
>>
>> Or will future patches add code that depends on internal interfaces of
>> scsi-disk?
>
> It already uses some internal interfaces: scsi_initfn, scsi_disk_reset,
> scsi_destroy, sizeof(SCSIDiskState).
Right... I don't like it much in scsi-disk.c, but what can you do.
Exporting everything wouldn't be nicer.
Kevin
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 15:34 UTC (permalink / raw)
To: Linus Walleij, Russell King - ARM Linux
Cc: Sebastian Rasmussen, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4EA58368.6050704@stericsson.com>
Ulf Hansson wrote:
> Linus Walleij wrote:
>> On Mon, Oct 24, 2011 at 1:48 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>>> [Russell]
>>>> The MCIPWR signal controls the external power switch. This is the only
>>>> signal for it. This is the only connection for it. There is no other
>>>> control form for this power switch.
>>>>
>>> Then we are only left to use the variant struct I believe. In principle, a
>>> flag in the variant struct, could indicate whether it is OK to disable the
>>> vcore regulator and thus clear the MCIPWR when doing runtime_suspend.
>> Yep I think the best could be to add some variant named
>> bool external_card_power; and then document in the kerneldoc that this
>> means the driver can clear MMCIPWR without risk of cutting the power
>> to the card.
>>
>> This should be true for Ux500, U300 and Nomadik (just checked the designs -
>> they all have external regulators).
>>
>
> Could we assume that all boards which utilizes the ARM PL180 are using
> the MMCIPWR register to control power the card? Or should we add a new
> amba mmci platform member so this is configurable for each board?
>
> An option could also be if we might want to simplify code to just skip
> the entire runtime_suspend|idle|resume function (ie stubb it or
> something) for these kind of boards?
>
> What do you prefer?
By the way, there is also another option. In the runtime_suspend
function for ARM PL180 block we can use mmc_power_save_host (and then
also disable vcore etc) and vice verse in runtime_resume with
mmc_power_restore_host.
Of course, these kind of operations takes quite some time to execute and
therefore we use a much bigger timeout than 50 ms (for example 10 s
instead) for ARM PL180.
Just an idea...
>
>> So the state save/restore and amba_vcore_disable(adev); should be done
>> only for those variants.
>>
>> However this:
>>
>> clk_disable(host->clk);
>>
>> We ought to be able to do for *all* variants, provided we can create
>> pm_runtime_get/put and delay properly to cover all bus traffic
>> (looks like the patch already does that), plus all the time the card is
>> signalling busy. The best I can think of is to just return -EBUSY to runtime
>> PM like this:
>>
>> if ((readl(base + MMCISTATUS) & (MCI_CMDACTIVE | MCI_TXACTIVE| MCI_RXACTIVE))
>> return -EBUSY;
>>
>> Yours,
>> Linus Walleij
>>
>
>
^ permalink raw reply
* Re: [PATCH V2 2/4] MIPS: Add board support for Loongson1B
From: Giuseppe CAVALLARO @ 2011-10-24 15:35 UTC (permalink / raw)
To: Kelvin Cheung
Cc: Wu Zhangjin, linux-mips, linux-kernel, ralf, r0bertz, netdev
In-Reply-To: <CAJhJPsXxUAuF9HdivLd66MQC45mz-iYAuF1SdGdU=-duxJJ5bQ@mail.gmail.com>
On 10/24/2011 4:05 PM, Kelvin Cheung wrote:
> 2011/10/24, Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>> Hello Kelvin.
>>
>> On 10/24/2011 12:36 PM, Kelvin Cheung wrote:
>>
>> [snip]
>>
>>> According to datasheet of Loongson 1B, the buffer size in RX/TX
>>> descriptor is only 2KB. So the Loongson1B's GMAC could not handle
>>> jumbo frames. And the second buffer is useless in this case. Am I
>>> right? Is there a better way than ifdef CONFIG_MACH_LOONGSON1 to
>>> avoid duplicate code?
>>
>> Sorry for my misunderstanding.
>>
>> I think you have to use the normal descriptor and remove the enh_desc
>> from the platform w/o modifying the driver at all.
>>
>> The driver will be able to select/configure all automatically (also jumbo).
>>
>> Let me know.
>
> That's the problem.
> The bitfield definition of Loongson1B is also different from normal descriptor.
The problem is not in the Loongson1B gmac.
The normal descriptor fields in the stmmac refer to an old synopsys
databook.
New chips have the same structure you have added; so we should fix this
in the driver w/o breaking the compatibility for old chips.
I kindly ask you to confirm if the currently normal descriptor structure
(w/o your changes) doesn't work on your platform.
Did you test it?
> Moreover, I want to enable the TX checksum offload function which is
> not supported in normal descriptor.
> Any suggestions?
It is supported but you have to pass from the platform: tx_coe = 1.
Peppe
>
>> Note:
>> IIRC, there is a bit difference in case of normal descriptors for
>> Synopsys databook newer than the 1.91 (I used for testing this mode).
>> In any case, I remember that, on some platforms, the normal descriptors
>> have been used w/o problems also on these new chip generations.
>>
>> Peppe
>>
>>
>
>
^ permalink raw reply
* RE: [PATCHv4] DMAEngine: Define interleaved transfer request api
From: Vinod Koul @ 2011-10-24 15:27 UTC (permalink / raw)
To: Bounine, Alexandre, Russell King, Williams, Dan J
Cc: Jassi Brar, Barry Song, linux-kernel, DL-SHA-WorkGroupLinux,
Dave Jiang
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E5520236801F@CORPEXCH1.na.ads.idt.com>
On Mon, 2011-10-24 at 05:36 -0700, Bounine, Alexandre wrote:
> > I think we all agree that this fits the dma_slave case :)
> >
> > As for changing in dmaengine to u64, if we are thinking this as
> slave
> > usage, then ideally we should not make assumption of the address
> type
> > of
> > peripheral so we should only move the dma_slave_config address
> fields
> > to
> > u64, if that helps in RIO case. Moving other usages would be insane.
> >
> > At this point we have two proposals
> > a) to make RIO exceptional case and add RIO specific stuff.
> > b) make dmaengine transparent and add additional argument
> > in .device_prep_slave_sg() callback which is subsystem dependent.
> > Current dmacs and those who don't need it will ignore it.
> >
> > ATM, I am leaning towards the latter, for the main reason to keep
> > dmaengine away from subsystem details.
> >
> Both proposals will work for RapidIO but second option looks more
> universal and may be used by another subsystem in the future.
> My vote goes to the option b).
Thanks for the vote :D
I would really like to hear from Dan, Jassi and Russell as well.
--
~Vinod
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 29/35] scsi-disk: remove cluster_size
From: Paolo Bonzini @ 2011-10-24 15:36 UTC (permalink / raw)
To: Kevin Wolf; +Cc: qemu-devel
In-Reply-To: <4EA57FD6.4070703@redhat.com>
On 10/24/2011 05:10 PM, Kevin Wolf wrote:
>> > - bdrv_get_geometry(s->qdev.conf.bs,&nb_sectors);
>> > - nb_sectors /= s->cluster_size;
>> > - if (nb_sectors) {
>> > - nb_sectors--;
>> > + if (s->qdev.blocksize) {
> When would it be 0? And wouldn't we crash with a zero blocksize anyway?
blocksize can be zero when passing through a removable medium and no
medium has ever been inserted in the disk since the guest was started.
In practice it won't crash because the guest will always send READ
CAPACITY first, will see a unit attention condition, and will not
attempt a read.
A more complete solution involves asking raw-posix for the logical block
size (right now logical_block_size acts as both the emulated and host
block size). This would also be useful to make cache=none work with
4k-sector disks without manually specifying logical_block_size.
However, it's not 1.0 material.
Paolo
^ permalink raw reply
* [Buildroot] libtool: Version mismatch error
From: marco_cantu_ranzani at libero.it @ 2011-10-24 15:36 UTC (permalink / raw)
To: buildroot
./libtool: line 1300: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
The same problem but while compiling PTH 2.0.7
Anyone?
^ permalink raw reply
* [PATCH 1/2] sparse, llvm: Use new LLVM type system API for structs
From: Pekka Enberg @ 2011-10-24 15:37 UTC (permalink / raw)
To: linux-sparse; +Cc: Pekka Enberg, Christopher Li, Jeff Garzik, Linus Torvalds
To fix an issue with structs that refer to themselves:
struct symbol {
struct symbol *next;
};
convert the code to use new type system API introduced in LLVM 3.0 so that
there's a LLVMTypeRef of the struct we can look up while walking through the
struct members.
Cc: Christopher Li <sparse@chrisli.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
---
sparse-llvm.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/sparse-llvm.c b/sparse-llvm.c
index fc0c2e9..14744e5 100644
--- a/sparse-llvm.c
+++ b/sparse-llvm.c
@@ -40,15 +40,26 @@ static LLVMTypeRef sym_struct_type(struct symbol *sym)
{
LLVMTypeRef elem_types[MAX_STRUCT_MEMBERS];
struct symbol *member;
+ char buffer[256];
+ LLVMTypeRef ret;
unsigned nr = 0;
+ sprintf(buffer, "%.*s", sym->ident->len, sym->ident->name);
+
+ ret = LLVMStructCreateNamed(LLVMGetGlobalContext(), buffer);
+
FOR_EACH_PTR(sym->symbol_list, member) {
+ LLVMTypeRef member_type;
+
assert(nr < MAX_STRUCT_MEMBERS);
- elem_types[nr++] = symbol_type(member);
+ member_type = symbol_type(member);
+
+ elem_types[nr++] = member_type;
} END_FOR_EACH_PTR(member);
- return LLVMStructType(elem_types, nr, 0 /* packed? */);
+ LLVMStructSetBody(ret, elem_types, nr, 0 /* packed? */);
+ return ret;
}
static LLVMTypeRef sym_ptr_type(struct symbol *sym)
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH v4 0/4] ILK VT-d fix
From: Keith Packard @ 2011-10-24 15:37 UTC (permalink / raw)
To: Woodhouse, David, Ben Widawsky
Cc: Dave Airlie, intel-gfx@lists.freedesktop.org, Qu, Yan
In-Reply-To: <1319443974.13738.85.camel@shinybook.infradead.org>
[-- Attachment #1.1: Type: text/plain, Size: 396 bytes --]
On Mon, 24 Oct 2011 08:14:45 +0000, "Woodhouse, David" <david.woodhouse@intel.com> wrote:
> The IOMMU patches are now in Linus' tree and thus will be in the 3.1
> release. Are we going to push the graphics patches in time for the 3.1
> release too?
The graphics patches are in the 3.2 pull request; they'll be available
for the 3.1 stable series though.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 2/2] sparse, llvm: Fix struct code generation
From: Pekka Enberg @ 2011-10-24 15:37 UTC (permalink / raw)
To: linux-sparse; +Cc: Pekka Enberg, Christopher Li, Jeff Garzik, Linus Torvalds
In-Reply-To: <1319470642-21031-1-git-send-email-penberg@kernel.org>
Use LLVMGetTypeByName() to look up struct data types to fix code generation for
structs that refer to themselves.
Cc: Christopher Li <sparse@chrisli.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
---
sparse-llvm.c | 50 +++++++++++++++++++++++-------------------
validation/backend/struct.c | 1 +
2 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/sparse-llvm.c b/sparse-llvm.c
index 14744e5..5d1b79c 100644
--- a/sparse-llvm.c
+++ b/sparse-llvm.c
@@ -32,11 +32,11 @@ static inline bool symbol_is_fp_type(struct symbol *sym)
return sym->ctype.base_type == &fp_type;
}
-static LLVMTypeRef symbol_type(struct symbol *sym);
+static LLVMTypeRef symbol_type(LLVMModuleRef module, struct symbol *sym);
#define MAX_STRUCT_MEMBERS 64
-static LLVMTypeRef sym_struct_type(struct symbol *sym)
+static LLVMTypeRef sym_struct_type(LLVMModuleRef module, struct symbol *sym)
{
LLVMTypeRef elem_types[MAX_STRUCT_MEMBERS];
struct symbol *member;
@@ -46,6 +46,10 @@ static LLVMTypeRef sym_struct_type(struct symbol *sym)
sprintf(buffer, "%.*s", sym->ident->len, sym->ident->name);
+ ret = LLVMGetTypeByName(module, buffer);
+ if (ret)
+ return ret;
+
ret = LLVMStructCreateNamed(LLVMGetGlobalContext(), buffer);
FOR_EACH_PTR(sym->symbol_list, member) {
@@ -53,7 +57,7 @@ static LLVMTypeRef sym_struct_type(struct symbol *sym)
assert(nr < MAX_STRUCT_MEMBERS);
- member_type = symbol_type(member);
+ member_type = symbol_type(module, member);
elem_types[nr++] = member_type;
} END_FOR_EACH_PTR(member);
@@ -62,9 +66,9 @@ static LLVMTypeRef sym_struct_type(struct symbol *sym)
return ret;
}
-static LLVMTypeRef sym_ptr_type(struct symbol *sym)
+static LLVMTypeRef sym_ptr_type(LLVMModuleRef module, struct symbol *sym)
{
- LLVMTypeRef type = symbol_type(sym->ctype.base_type);
+ LLVMTypeRef type = symbol_type(module, sym->ctype.base_type);
return LLVMPointerType(type, 0);
}
@@ -112,22 +116,22 @@ static LLVMTypeRef sym_basetype_type(struct symbol *sym)
return ret;
}
-static LLVMTypeRef symbol_type(struct symbol *sym)
+static LLVMTypeRef symbol_type(LLVMModuleRef module, struct symbol *sym)
{
LLVMTypeRef ret = NULL;
switch (sym->type) {
case SYM_NODE:
- ret = symbol_type(sym->ctype.base_type);
+ ret = symbol_type(module, sym->ctype.base_type);
break;
case SYM_BASETYPE:
ret = sym_basetype_type(sym);
break;
case SYM_PTR:
- ret = sym_ptr_type(sym);
+ ret = sym_ptr_type(module, sym);
break;
case SYM_STRUCT:
- ret = sym_struct_type(sym);
+ ret = sym_struct_type(module, sym);
break;
default:
assert(0);
@@ -135,10 +139,10 @@ static LLVMTypeRef symbol_type(struct symbol *sym)
return ret;
}
-static LLVMTypeRef insn_symbol_type(struct instruction *insn)
+static LLVMTypeRef insn_symbol_type(LLVMModuleRef module, struct instruction *insn)
{
if (insn->type)
- return symbol_type(insn->type);
+ return symbol_type(module, insn->type);
switch (insn->size) {
case 8: return LLVMInt8Type();
@@ -234,7 +238,7 @@ static LLVMValueRef pseudo_to_value(struct function *fn, struct instruction *ins
break;
}
case PSEUDO_VAL:
- result = LLVMConstInt(insn_symbol_type(insn), pseudo->value, 1);
+ result = LLVMConstInt(insn_symbol_type(fn->module, insn), pseudo->value, 1);
break;
case PSEUDO_ARG: {
result = LLVMGetParam(fn->fn, pseudo->nr - 1);
@@ -265,7 +269,7 @@ static LLVMTypeRef pseudo_type(struct function *fn, struct instruction *insn, ps
switch (pseudo->type) {
case PSEUDO_REG:
- result = symbol_type(pseudo->def->type);
+ result = symbol_type(fn->module, pseudo->def->type);
break;
case PSEUDO_SYM: {
struct symbol *sym = pseudo->sym;
@@ -287,7 +291,7 @@ static LLVMTypeRef pseudo_type(struct function *fn, struct instruction *insn, ps
break;
}
case PSEUDO_VAL:
- result = insn_symbol_type(insn);
+ result = insn_symbol_type(fn->module, insn);
break;
case PSEUDO_ARG:
result = LLVMTypeOf(LLVMGetParam(fn->fn, pseudo->nr - 1));
@@ -691,7 +695,7 @@ static void output_op_phi(struct function *fn, struct instruction *insn)
pseudo_t phi;
LLVMValueRef target;
- target = LLVMBuildPhi(fn->builder, insn_symbol_type(insn),
+ target = LLVMBuildPhi(fn->builder, insn_symbol_type(fn->module, insn),
"phi");
int pll = 0;
FOR_EACH_PTR(insn->phi_list, phi) {
@@ -733,9 +737,9 @@ static void output_op_cast(struct function *fn, struct instruction *insn, LLVMOp
assert(!symbol_is_fp_type(insn->type));
if (insn->size < LLVMGetIntTypeWidth(LLVMTypeOf(src)))
- target = LLVMBuildTrunc(fn->builder, src, insn_symbol_type(insn), target_name);
+ target = LLVMBuildTrunc(fn->builder, src, insn_symbol_type(fn->module, insn), target_name);
else
- target = LLVMBuildCast(fn->builder, op, src, insn_symbol_type(insn), target_name);
+ target = LLVMBuildCast(fn->builder, op, src, insn_symbol_type(fn->module, insn), target_name);
insn->target->priv = target;
}
@@ -749,7 +753,7 @@ static void output_op_copy(struct function *fn, struct instruction *insn,
pseudo_name(insn->target, target_name);
src = pseudo_to_value(fn, insn, pseudo);
- const_type = insn_symbol_type(insn);
+ const_type = insn_symbol_type(fn->module, insn);
/*
* This is nothing more than 'target = src'
@@ -910,12 +914,12 @@ static void output_fn(LLVMModuleRef module, struct entrypoint *ep)
FOR_EACH_PTR(base_type->arguments, arg) {
struct symbol *arg_base_type = arg->ctype.base_type;
- arg_types[nr_args++] = symbol_type(arg_base_type);
+ arg_types[nr_args++] = symbol_type(module, arg_base_type);
} END_FOR_EACH_PTR(arg);
name = show_ident(sym->ident);
- return_type = symbol_type(ret_type);
+ return_type = symbol_type(module, ret_type);
function.module = module;
@@ -972,7 +976,7 @@ static int output_data(LLVMModuleRef module, struct symbol *sym)
if (initializer) {
switch (initializer->type) {
case EXPR_VALUE:
- initial_value = LLVMConstInt(symbol_type(sym), initializer->value, 1);
+ initial_value = LLVMConstInt(symbol_type(module, sym), initializer->value, 1);
break;
case EXPR_SYMBOL: {
struct symbol *sym = initializer->symbol;
@@ -984,14 +988,14 @@ static int output_data(LLVMModuleRef module, struct symbol *sym)
assert(0);
}
} else {
- LLVMTypeRef type = symbol_type(sym);
+ LLVMTypeRef type = symbol_type(module, sym);
initial_value = LLVMConstNull(type);
}
name = show_ident(sym->ident);
- data = LLVMAddGlobal(module, symbol_type(sym->ctype.base_type), name);
+ data = LLVMAddGlobal(module, symbol_type(module, sym->ctype.base_type), name);
LLVMSetLinkage(data, data_linkage(sym));
diff --git a/validation/backend/struct.c b/validation/backend/struct.c
index 9d0cb56..1afaf2d 100644
--- a/validation/backend/struct.c
+++ b/validation/backend/struct.c
@@ -6,6 +6,7 @@ struct symbol {
void *p;
const char *name;
struct ctype ctype;
+ struct symbol *next_id;
};
static struct symbol sym;
--
1.7.6.4
^ permalink raw reply related
* [Buildroot] Some topics for the Buildroot Developer Day
From: Thomas Petazzoni @ 2011-10-24 15:38 UTC (permalink / raw)
To: buildroot
Hello,
As discussed on IRC, I am posting below a list of topics that might be
discussed during the developer day. Note that this is just _my_ list of
topics, note the one of the Buildroot project as a whole. Moreover,
it's very likely that not all topics will be covered during our meeting
day. However, feel free to add your opinion and/or your additional
topics, especially if you can't make it to the Developer day.
Regards,
Thomas
ELCE 2011 meeting agenda
========================
* Migration to the Ascii-doc format, what remains to be done ?
Infrastructure on the web server side ?
* Extract sources in a new output/sources/ directory, and do
out-of-tree build of packages.
Pros:
- Allows more natural integration with the override source
directory mechanism. No rsync needed here, especially useful for
big packages such as the kernel.
- Allows to extract only once the source code for utitilies built
for the host and the target (X.org components, Glib/Gtk stack,
etc.)
- Should work fine for all CMake-based and autotools-based packages.
Cons:
- Not all packages support out-of-tree build. The infrastructure
should support a <pkg>_OUTOFTREE boolean, defaulting to NO for
all packages, overriden to YES for autotools-based and
CMake-based packages. When set to NO, the infrastructure will
have to copy/rsync the source code to the build directory. This
adds an additional copy of the source code for packages that
don't support out-of-tree build.
* Website improvement. The website is ugly, never changes, not
representative of the vivacity of the community. At least improve
the design. Wiki ? Blog ?
* Maintainance/patch review/merge. How to spread the load ? Should we
move to a model with trusted maintainers for specific parts of
Buildroot ? Usage of patchwork/Gerrit ?
* Host packages visible in menuconfig. Discussion has taken place on
the list, consensus reached between several contributors,
implementation proposed. What do we do ?
+ proposal of Arnout to derive host dependencies from target
dependencies.
* Per-package device files handling, proposed by Maxime Ripard.
* Testing infrastructure. Possible to put build results on the Web
server ? Common format for them ?
* Tracking of files installed by packages. Do we care ? Is this an
important feature of Buildroot ? Won't the added complexity make
Buildroot more complicated to understand ?
Which solution ? Two solutions:
- Change the installation steps of packages so that each package
installs in a different directory.
Pros:
seems to be the cleanest solution.
allows to easily detect packages overriding files installed by
other packages.
Cons:
requires modifications of all gentargets packages to use
$$(STAGING_DIR) and $$(TARGET_DIR) instead of $(STAGING_DIR)
and $(TARGET_DIR).
strange handling of host packages. DESTDIR isn't used, the
prefix is the absolute path to HOST_DIR.
- Keep installing package files in their normal directory, but
detect new files and modified files.
Pros:
no need to change anything in the current package installation
procedures.
Cons:
need to scan the TARGET_DIR, STAGING_DIR and HOST_DIR after
every package installation.
hard to detect modified/overwritten files, except by storing
hashes of installed files.
* Next big directions. What are the next big directions for Buildroot
? The major features we want to implement ?
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 5/6] IIO:hwmon interface client driver.
From: Guenter Roeck @ 2011-10-24 15:39 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
linus.ml.walleij@gmail.com, zdevai@gmail.com,
linux@arm.linux.org.uk, arnd@arndb.de,
broonie@opensource.wolfsonmicro.com, gregkh@suse.de,
lm-sensors@lm-sensors.org, khali@linux-fr.org,
thomas.petazzoni@free-electrons.com,
maxime.ripard@free-electrons.com
In-Reply-To: <4EA53973.9080102@cam.ac.uk>
On Mon, 2011-10-24 at 06:09 -0400, Jonathan Cameron wrote:
[ ... ]
> >>> +/*
> >>> + * Assumes that IIO and hwmon operate in the same base units.
> >>> + * This is supposed to be true, but needs verification for
> >>> + * new channel types.
> >>> + */
> >>> +static ssize_t iio_hwmon_read_val(struct device *dev,
> >>> + struct device_attribute *attr,
> >>> + char *buf)
> >>> +{
> >>> + long result;
> >>> + int val, ret, scaleint, scalepart;
> >>> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
> >>> + struct iio_hwmon_state *state = dev_get_drvdata(dev);
> >>> +
> >>> + /*
> >>> + * No locking between this pair, so theoretically possible
> >>> + * the scale has changed.
> >>> + */
> >>> + ret = iio_read_channel_raw(state->channels[sattr->index],
> >>> + &val);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> +
> >>> + ret = iio_read_channel_scale(state->channels[sattr->index],
> >>> + &scaleint, &scalepart);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> + switch (ret) {
> >>> + case IIO_VAL_INT:
> >>> + result = val * scaleint;
> >>> + break;
> >>> + case IIO_VAL_INT_PLUS_MICRO:
> >>> + result = (long)val * (long)scaleint +
> >>> + (long)val * (long)scalepart / 1000000L;
> >>> + break;
> >>> + case IIO_VAL_INT_PLUS_NANO:
> >>> + result = (long)val * (long)scaleint +
> >>> + (long)val * (long)scalepart / 1000000000L;
> >>> + break;
> >>
> >> Still easy to imagine that val * scalepart gets larger than 2147483647L
> >> (on machines where sizeof(long) = 4) ... it will already happen if the
> >> result of (val * scalepart / 1000000000) is larger than 2.
> > Good point. I really ought to have done the calcs.
> > If we have maximum possible value in here things will be ugly.
> >
> > Worst case is scalepart is 9999999999. (could be done as 1 - 0.000000001
> > which would be nicer, but we don't specify a preference - from this
> > discussion I am suspecting we should!)
> >
> > Looks like 64 bits is going to be a requirement as you say.
> >>
> >> What value range do you expect to see here ?
> >>
> >> If (val * scaleint) is already the milli-unit, scalepart would possibly
> >> only address fractions of milli-units. If so, the result of (val *
> >> scalepart / 1000000000L) might always be smaller than 1, ie 0.
> > It certainly should be.
> >> If so, for the calculation to have any value, you might be better off using
> >> DIV_ROUND_CLOSEST(val * scalepart, 1000000000L).
> > Good idea.
> >>
> >> I am a bit confused by this anyway. Since hwmon in general reports
> >> milli-units, VAL_INT appears to reflect milli-units, VAL_INT_PLUS_MICRO
> >> really means nano-units, and IIO_VAL_INT_PLUS_NANO really means
> >> pico-units. Is this correct ?
> > Micro units of the scale factor.
> >
> > Take my test part a max1363...
> > Scale is actually 0.5 so each adc count (e.g. raw value) is 0.5millivolts.
> >
> > scale int here is 0,
> > scale part is 500,000 (so 0.5) and it returns IIO_VAL_INT_PLUS_MICRO.
>
> How about the following? It'll be extremely costly, but this isn't exactly
> a fast path!
>
> case IIO_VAL_INT_PLUS_MICRO:
> result = (s64)val * (s64)scaleint +
> div_s64((s64)val * (s64)scalepart, 1000000LL);
> break;
> case IIO_VAL_INT_PLUS_NANO:
> result = (s64)val * (s64)scaleint +
> div_s64((s64)val * (s64)scalepart, 1000000000LL);
> break;
Is div_s64 really necessary, or would
result = (long)val * (long)scaleint +
DIV_ROUND_CLOSEST((s64)val * (s64)scalepart,
1000000000LL);
work as well ?
Thanks,
Guenter
^ permalink raw reply
* Re: [lm-sensors] [PATCH 5/6] IIO:hwmon interface client driver.
From: Guenter Roeck @ 2011-10-24 15:39 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
linus.ml.walleij@gmail.com, zdevai@gmail.com,
linux@arm.linux.org.uk, arnd@arndb.de,
broonie@opensource.wolfsonmicro.com, gregkh@suse.de,
lm-sensors@lm-sensors.org, khali@linux-fr.org,
thomas.petazzoni@free-electrons.com,
maxime.ripard@free-electrons.com
In-Reply-To: <4EA53973.9080102@cam.ac.uk>
On Mon, 2011-10-24 at 06:09 -0400, Jonathan Cameron wrote:
[ ... ]
> >>> +/*
> >>> + * Assumes that IIO and hwmon operate in the same base units.
> >>> + * This is supposed to be true, but needs verification for
> >>> + * new channel types.
> >>> + */
> >>> +static ssize_t iio_hwmon_read_val(struct device *dev,
> >>> + struct device_attribute *attr,
> >>> + char *buf)
> >>> +{
> >>> + long result;
> >>> + int val, ret, scaleint, scalepart;
> >>> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
> >>> + struct iio_hwmon_state *state = dev_get_drvdata(dev);
> >>> +
> >>> + /*
> >>> + * No locking between this pair, so theoretically possible
> >>> + * the scale has changed.
> >>> + */
> >>> + ret = iio_read_channel_raw(state->channels[sattr->index],
> >>> + &val);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> +
> >>> + ret = iio_read_channel_scale(state->channels[sattr->index],
> >>> + &scaleint, &scalepart);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> + switch (ret) {
> >>> + case IIO_VAL_INT:
> >>> + result = val * scaleint;
> >>> + break;
> >>> + case IIO_VAL_INT_PLUS_MICRO:
> >>> + result = (long)val * (long)scaleint +
> >>> + (long)val * (long)scalepart / 1000000L;
> >>> + break;
> >>> + case IIO_VAL_INT_PLUS_NANO:
> >>> + result = (long)val * (long)scaleint +
> >>> + (long)val * (long)scalepart / 1000000000L;
> >>> + break;
> >>
> >> Still easy to imagine that val * scalepart gets larger than 2147483647L
> >> (on machines where sizeof(long) = 4) ... it will already happen if the
> >> result of (val * scalepart / 1000000000) is larger than 2.
> > Good point. I really ought to have done the calcs.
> > If we have maximum possible value in here things will be ugly.
> >
> > Worst case is scalepart is 9999999999. (could be done as 1 - 0.000000001
> > which would be nicer, but we don't specify a preference - from this
> > discussion I am suspecting we should!)
> >
> > Looks like 64 bits is going to be a requirement as you say.
> >>
> >> What value range do you expect to see here ?
> >>
> >> If (val * scaleint) is already the milli-unit, scalepart would possibly
> >> only address fractions of milli-units. If so, the result of (val *
> >> scalepart / 1000000000L) might always be smaller than 1, ie 0.
> > It certainly should be.
> >> If so, for the calculation to have any value, you might be better off using
> >> DIV_ROUND_CLOSEST(val * scalepart, 1000000000L).
> > Good idea.
> >>
> >> I am a bit confused by this anyway. Since hwmon in general reports
> >> milli-units, VAL_INT appears to reflect milli-units, VAL_INT_PLUS_MICRO
> >> really means nano-units, and IIO_VAL_INT_PLUS_NANO really means
> >> pico-units. Is this correct ?
> > Micro units of the scale factor.
> >
> > Take my test part a max1363...
> > Scale is actually 0.5 so each adc count (e.g. raw value) is 0.5millivolts.
> >
> > scale int here is 0,
> > scale part is 500,000 (so 0.5) and it returns IIO_VAL_INT_PLUS_MICRO.
>
> How about the following? It'll be extremely costly, but this isn't exactly
> a fast path!
>
> case IIO_VAL_INT_PLUS_MICRO:
> result = (s64)val * (s64)scaleint +
> div_s64((s64)val * (s64)scalepart, 1000000LL);
> break;
> case IIO_VAL_INT_PLUS_NANO:
> result = (s64)val * (s64)scaleint +
> div_s64((s64)val * (s64)scalepart, 1000000000LL);
> break;
Is div_s64 really necessary, or would
result = (long)val * (long)scaleint +
DIV_ROUND_CLOSEST((s64)val * (s64)scalepart,
1000000000LL);
work as well ?
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* [PATCH v2] gpio: pl061: add DT binding support
From: Rob Herring @ 2011-10-24 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E7BBFF5.5090001@gmail.com>
Grant,
On 09/22/2011 06:08 PM, Rob Herring wrote:
> Grant,
>
> On 08/10/2011 04:31 PM, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> This adds devicetree binding support to the ARM pl061 driver removing the
>> platform_data dependency. When DT binding is used, the gpio numbering is
>> assigned dynamically. For now, interrupts are not supported with DT until
>> irqdomains learn dynamic irq assignment.
>>
>> Rather than add another case of -1, updating the driver to use NO_IRQ.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> ---
>
> Ping. Any comments on this?
>
Ping. Can you apply this for 3.2.
Rob
> Rob
>>
>> v2:
>> - Add other -1 to NO_IRQ conversions
>> - Drop DT irq support for now
>>
>> drivers/gpio/gpio-pl061.c | 31 +++++++++++++++++++++----------
>> include/linux/amba/pl061.h | 3 +--
>> 2 files changed, 22 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
>> index 2c5a18f..093c90b 100644
>> --- a/drivers/gpio/gpio-pl061.c
>> +++ b/drivers/gpio/gpio-pl061.c
>> @@ -118,7 +118,7 @@ static int pl061_to_irq(struct gpio_chip *gc, unsigned offset)
>> {
>> struct pl061_gpio *chip = container_of(gc, struct pl061_gpio, gc);
>>
>> - if (chip->irq_base == (unsigned) -1)
>> + if (chip->irq_base == NO_IRQ)
>> return -EINVAL;
>>
>> return chip->irq_base + offset;
>> @@ -246,6 +246,18 @@ static int pl061_probe(struct amba_device *dev, const struct amba_id *id)
>> if (chip == NULL)
>> return -ENOMEM;
>>
>> + pdata = dev->dev.platform_data;
>> + if (pdata) {
>> + chip->gc.base = pdata->gpio_base;
>> + chip->irq_base = pdata->irq_base;
>> + } else if (dev->dev.of_node) {
>> + chip->gc.base = -1;
>> + chip->irq_base = NO_IRQ;
>> + } else {
>> + ret = -ENODEV;
>> + goto free_mem;
>> + }
>> +
>> if (!request_mem_region(dev->res.start,
>> resource_size(&dev->res), "pl061")) {
>> ret = -EBUSY;
>> @@ -267,14 +279,11 @@ static int pl061_probe(struct amba_device *dev, const struct amba_id *id)
>> chip->gc.get = pl061_get_value;
>> chip->gc.set = pl061_set_value;
>> chip->gc.to_irq = pl061_to_irq;
>> - chip->gc.base = pdata->gpio_base;
>> chip->gc.ngpio = PL061_GPIO_NR;
>> chip->gc.label = dev_name(&dev->dev);
>> chip->gc.dev = &dev->dev;
>> chip->gc.owner = THIS_MODULE;
>>
>> - chip->irq_base = pdata->irq_base;
>> -
>> ret = gpiochip_add(&chip->gc);
>> if (ret)
>> goto iounmap;
>> @@ -283,7 +292,7 @@ static int pl061_probe(struct amba_device *dev, const struct amba_id *id)
>> * irq_chip support
>> */
>>
>> - if (chip->irq_base == (unsigned) -1)
>> + if (chip->irq_base == NO_IRQ)
>> return 0;
>>
>> writeb(0, chip->base + GPIOIE); /* disable irqs */
>> @@ -307,11 +316,13 @@ static int pl061_probe(struct amba_device *dev, const struct amba_id *id)
>> list_add(&chip->list, chip_list);
>>
>> for (i = 0; i < PL061_GPIO_NR; i++) {
>> - if (pdata->directions & (1 << i))
>> - pl061_direction_output(&chip->gc, i,
>> - pdata->values & (1 << i));
>> - else
>> - pl061_direction_input(&chip->gc, i);
>> + if (pdata) {
>> + if (pdata->directions & (1 << i))
>> + pl061_direction_output(&chip->gc, i,
>> + pdata->values & (1 << i));
>> + else
>> + pl061_direction_input(&chip->gc, i);
>> + }
>>
>> irq_set_chip_and_handler(i + chip->irq_base, &pl061_irqchip,
>> handle_simple_irq);
>> diff --git a/include/linux/amba/pl061.h b/include/linux/amba/pl061.h
>> index 5ddd9ad..2412af9 100644
>> --- a/include/linux/amba/pl061.h
>> +++ b/include/linux/amba/pl061.h
>> @@ -7,8 +7,7 @@ struct pl061_platform_data {
>> unsigned gpio_base;
>>
>> /* number of the first IRQ.
>> - * If the IRQ functionality in not desired this must be set to
>> - * (unsigned) -1.
>> + * If the IRQ functionality in not desired this must be set to NO_IRQ.
>> */
>> unsigned irq_base;
>>
>
^ permalink raw reply
* [Buildroot] GnuPG
From: ilranzani @ 2011-10-24 15:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <8167afaddbb08fc25202dbf489d78389@zacarias.com.ar>
Steps:
+ LIBKSBA
+ LIBASSUAN
=== pth
- gnupg
- gpgme
- opgk
While compiling PTH 2.0.7
./libtool: line 1300: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.
make[1]: *** [pth_uctx.lo] Error 63
make[1]: *** Waiting for unfinished jobs....
Gustavo Zacarias-2 wrote:
>
> On 24.10.2011 08:12, ilranzani wrote:
>
>> Nobody?
>>
>> (in buildroot there's already libgcrypt)
>>
>> UP UP UP ! :)
>
> It's not too hard, you just need to add a couple of extra libraries
> (packages) that it needs, IIRC libassuan and libksba.
> The rest of the mandatory dependencies are already available
> (libgpg-error & libgcrypt).
> Regards.
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
--
View this message in context: http://old.nabble.com/GnuPG-tp29967586p32711202.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
^ 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.