please pull from 'for-next' branch at
to receive patches queued in trivial tree. Mostly spelling fixes, removals
of unnecessary casts and update of broken URLs all over the tree.
Anton Blanchard (1):
Fix spelling mistake in jhash
H Hartley Sweeten (2):
arm: scoop.c: remove C99 comments
arm: uengine.c: remove C99 comments
Jiri Kosina (4):
paravirt: noreplace-paravirt is implemented for x86 and ia-64
Revert "drivers/usb: Remove unnecessary return's from void functions" partially
Revert "Fix typo: configuation => configuration" partially
Revert "drivers/usb: Remove unnecessary return's from void functions" for musb gadget
Joe Perches (9):
drivers/usb: Remove unnecessary return's from void functions
fs/seq_file.c: Remove unnecessary casts of private_data
fs/ecryptfs: Remove unnecessary casts of private_data
kernel/pm_qos_params.c: Remove unnecessary casts of private_data
drivers/gpu/drm: Remove unnecessary casts of private_data
drivers/infiniband: Remove unnecessary casts of private_data
net/sunrpc/rpc_pipe.c: Remove unnecessary casts of private_data
drivers/s390: Remove unnecessary casts of private_data
drivers/scsi: Remove unnecessary casts of private_data
Justin P. Mattock (5):
vesafb: fix comment a typo
include/video/vga.h: update web address.
MAINTAINERS: update broken web address
Update broken web addresses in the kernel.
Update broken web addresses in arch directory.
Namhyung Kim (3):
fix a typo on comments in mm/percpu.c
ext2: fix a typo on comment in ext2/inode.c
ida: document IDA_BITMAP_LONGS calculation
Naohiro Aota (2):
idr: fix kernel-doc warnings.
idr: describe how nextidp works in idr_get_next().
Niels de Vos (1):
parport_pc: show the detection of a 2 serial port ITE8874 chip
Nikanth Karthikesan ...
Pulled. With one modification: I didn't take the top merge commit.
I _really_ prefer to see the clashes myself, and the extra merges just
make history less readable. So if the conflicts are trivial, please
don't pre-merge stuff - it just hides things from me.
Now, admittedly the things it hides shouldn't matter for something
like the trivial tree, but at the same time, exactly because it's the
trivial tree I would also expect the conflicts to be really trivial,
so I'd rather just have people follow the general rule of "please
don't pre-merge" regardless.
It's a good idea to perhaps do a private merge just to see how nasty
things are, and to perhaps give me a heads-up (and maybe even export
the pre-merged thing as a "btw, if you're lazy and don't care about
the conflicts, you can pull this other pre-merged branch" branch). But
on the whole, I tend to find the conflicts to be the most telling
parts of any merge, and be a good hint about what development trees
clashed with each other.
OK, I always do private merge with your latest tree to see what actually
happens, and only merge with latest state of your tree whenever there is
conflict. But deferring this to you (with warning in the pull request) is
obviously fine with me as well.
SUSE Labs, Novell Inc.