Reformat structure initializers to match the rest of input handlers
Reviewed-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Kirill noted the following deadlock cycle on shutdown involving padata:
> With commit 755609a908 I've got deadlock on
> poweroff.
>
> It guess it happens because of race for cpu_hotplug.lock:
>
> CPU A CPU B
> disable_nonboot_cpus()
> _cpu_down()
> cpu_hotplug_begin()
> mutex_lock(&cpu_hotplug.lock);
> __cpu_notify()
> padata_cpu_callback()
> __padata_remove_cpu()
> padata_replace()
> synchronize_rcu()
> rcu_gp_kthread()
> get_online_cpus();
> mutex_lock(&cpu_hotplug.lock);
It would of course be good to eliminate grace-period delays from
CPU-hotplug notifiers, but that is a separate issue. Deadlock is
not an appropriate diagnostic for excessive CPU-hotplug latency.
Fortunately, grace-period initialization does not actually need to
exclude all of the CPU-hotplug operation, but rather only RCU's own
CPU_UP_PREPARE and CPU_DEAD CPU-hotplug notifiers. This commit therefore
introduces a new per-rcu_state onoff_mutex that provides the required
concurrency control in place of the get_online_cpus() that was previously
in rcu_gp_init().
Reported-by: "Kirill A. Shutemov" <kirill@shutemov.name>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
The generic implementation of compat_sys_sendfile() has been introduced
by commit 8f9c0119. This patch removes the arm64 implementation in
favour of the generic one.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Following commit 74838b7 (swiotlb: add the late swiotlb initialization
function with iotlb memory) the swiotlb_init_with_default_size() is a
static function. This patch changes the arm64 code to call
swiotlb_init() instead and use the default size of 64MB. It is assumed
that AArch64 platforms have enough RAM to afford the pre-allocated
swiotlb memory. It also removes the #ifdef around this call since
CONFIG_SWIOTLB is always enabled.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
From what I can conclude all GPIO handling was removed in 2009.
Remove dead code remnants.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Weinberger from Linutronix. Fastmap is designed to address UBI's slow scanning
issues. Namely, it introduces a new on-flash data-structure called "fastmap",
which stores the information about logical<->physical eraseblocks mappings.
So now to get this information just read the fastmap, instead of doing full
scan. More information here can be found in Richard's announcement in LKML
(Subject: UBI: Fastmap request for inclusion (v19)):
http://thread.gmane.org/gmane.linux.kernel/1364922/focus=1369109
One thing I want to explicitly say is that fastmap did not have large
enough linux-next exposure. It is partially my fault - I did not respond
quickly enough. I _really_ apologize for this. But it had good testing and
disabled by default, so I do not expect that we'll break anything.
Fastmap is declared as experimental so far, and it is off by default. We
did declare that the on-flash format may be changed. The reason for this is
that no one used it in real production so far, so there is a high risk that
something is missing. Besides, we do not have user-space tools supporting
fastmap so far.
Nevertheless, I suggest we merge this feature. Many people want UBI's scanning
bottleneck to be fixed and merging fastmap now should accelerate its production
use. The plan is to make it bullet-prove, somewhat clean-up, and make it the
default for UBI. I do not know how many kernel releases will it take.
Basically, I what I want to do for fastmap is something like Linus did for
btrfs few years ago.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQcrPrAAoJECmIfjd9wqK0gjYQAJICGYdYBO2wXQKojN+c518j
dhZxSFBmn6VAVaLoiRJudbzVLiJXtEOupldnmfFqcBbM2I3KujkiVAb8kH99NNxH
orfbSXmi6fvLZd1FWKm6EETl1CwWeOvQHcewLtGEdlhMqjNxo9QwZSxDNEARwBK8
rCchMnR7QgnmKZQActxg/PfdKHmFgZf9mj/IkcLXvYhV3MimBeRjA+gKwJHQ4R7g
+LWm2wkqEFpDqbtRIrJGsXkaX4f4oVK+KqTvOudsSMc5VD6R+xVjFux7MFz9DOYZ
copqR/3Ep0O+xeVgUm6it/rGubdU/ejr0T5kF/EEmDe2ktn8/7eGDh4VMx+4AyES
Vf18rD9Wc8eEcImcm/yxVY6FQRQjKT2tRF2TEarrhLAxXREsiYzLghRUuspgIcJG
hqQsNqJyDvV/YNBZIqVyA7sx0TDaP/8CwNYy7NiVYtxsVeo9QyzWer0aaHjmIeBL
AyEn5/2m7FVPL3acoLN4jAwyMNuDnQ3iuNqIhm2drm2brrxAcYUmWg/mXORlZpKM
Q8ts0h4++sTWgwuOEM/iCfoHagxJc3cQMsE6C1Z7LdLsNFHAPdnKSSkkjXK54jqx
wq1yapCkNDqzwWU4xjWsr7QaMLb69KPltx4Iw4wBE+8lW4WjqRdFhBs/+f3zceBe
SaSUuYkTFij+Ol+XWJnL
=/Sqc
-----END PGP SIGNATURE-----
Merge tag 'upstream-3.7-rc1-fastmap' of git://git.infradead.org/linux-ubi
Pull UBI fastmap changes from Artem Bityutskiy:
"This pull request contains the UBI fastmap support implemented by
Richard Weinberger from Linutronix. Fastmap is designed to address
UBI's slow scanning issues. Namely, it introduces a new on-flash
data-structure called "fastmap", which stores the information about
logical<->physical eraseblocks mappings. So now to get this
information just read the fastmap, instead of doing full scan. More
information here can be found in Richard's announcement in LKML
(Subject: UBI: Fastmap request for inclusion (v19)):
http://thread.gmane.org/gmane.linux.kernel/1364922/focus=1369109
One thing I want to explicitly say is that fastmap did not have large
enough linux-next exposure. It is partially my fault - I did not
respond quickly enough. I _really_ apologize for this. But it had
good testing and disabled by default, so I do not expect that we'll
break anything.
Fastmap is declared as experimental so far, and it is off by default.
We did declare that the on-flash format may be changed. The reason
for this is that no one used it in real production so far, so there is
a high risk that something is missing. Besides, we do not have
user-space tools supporting fastmap so far.
Nevertheless, I suggest we merge this feature. Many people want UBI's
scanning bottleneck to be fixed and merging fastmap now should
accelerate its production use. The plan is to make it bullet-prove,
somewhat clean-up, and make it the default for UBI. I do not know how
many kernel releases will it take.
Basically, I what I want to do for fastmap is something like Linus did
for btrfs few years ago."
* tag 'upstream-3.7-rc1-fastmap' of git://git.infradead.org/linux-ubi:
UBI: Wire-up fastmap
UBI: Add fastmap core
UBI: Add fastmap support to the WL sub-system
UBI: Add fastmap stuff to attach.c
UBI: Wire-up ->fm_sem
UBI: Add fastmap bits to build.c
UBI: Add self_check_eba()
UBI: Export next_sqnum()
UBI: Add fastmap stuff to ubi.h
UBI: Add fastmap on-flash data structures
Fixed messages for misconfigured port errors to be consistent for
all OS platforms.
Signed-off-by: James Smart <james.smart@emulex.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
This patch implements DMA support into mxs-i2c. DMA transfers are now enabled
via DT. The DMA operation is enabled by default.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
[wsa: rebased to 3.6-rc7]
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJQX7MuAAoJEHm+PkMAQRiG0h0IAJURkrMCAQUxA+Ik66ReH89s
LQcVd0U9uL4UUOi7f5WR64Vf9Cfu6VVGX9ZKSvjpNskvlQaUQPMIt4pMe6g4X4dI
u0bApEy4XZz3nGabUAghIU8jJ8cDmhCG6kPpSiS7pi7KHc0yIa4WFtJRrIpGaIWT
xuK38YOiOHcSDRlLyWZzainMncQp/ixJdxnqVMTonkVLk0q0b84XzOr4/qlLE5lU
i+TsK3PRKdQXgvZ4CebL+srPBwWX1dmgP3VkeBloQbSSenSeELICbFWavn2ml+sF
GXi4dO93oNquL/Oy5SwI666T4uNcrRPaS+5X+xSZgBW/y2aQVJVJuNZg6ZP/uWk=
=0v2l
-----END PGP SIGNATURE-----
Merge tag 'v3.6-rc7' into i2c-embedded/for-next
Linux 3.6-rc7
Needed to get updates from i2c-embedded/for-current into i2c-embedded/for-next
R-Car I2C is similar with SH7760 I2C.
But the SH7760 I2C driver had many workaround operations, since H/W had bugs.
Thus, it was pointless to keep compatible between SH7760 and R-Car I2C drivers.
This patch creates new Renesas R-Car I2C driver.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Pill drm updates part 2 from Dave Airlie:
"This is the follow-up pull, 3 pieces
a) exynos next stuff, was delayed but looks okay to me, one patch in
v4l bits but it was acked by v4l person.
b) UAPI disintegration bits
c) intel fixes - DP fixes, hang fixes, other misc fixes."
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (52 commits)
drm: exynos: hdmi: remove drm common hdmi platform data struct
drm: exynos: hdmi: add support for exynos5 hdmi
drm: exynos: hdmi: replace is_v13 with version check in hdmi
drm: exynos: hdmi: add support for exynos5 mixer
drm: exynos: hdmi: add support to disable video processor in mixer
drm: exynos: hdmi: add support for platform variants for mixer
drm: exynos: hdmi: add support for exynos5 hdmiphy
drm: exynos: hdmi: add support for exynos5 ddc
drm: exynos: remove drm hdmi platform data struct
drm: exynos: hdmi: turn off HPD interrupt in HDMI chip
drm: exynos: hdmi: use s5p-hdmi platform data
drm: exynos: hdmi: fix interrupt handling
drm: exynos: hdmi: support for platform variants
media: s5p-hdmi: add HPD GPIO to platform data
UAPI: (Scripted) Disintegrate include/drm
drm/i915: Fix GT_MODE default value
drm/i915: don't frob the vblank ts in finish_page_flip
drm/i915: call drm_handle_vblank before finish_page_flip
drm/i915: print warning if vmi915_gem_fault error is not handled
drm/i915: EBUSY status handling added to i915_gem_fault().
...
After use generic smp helpers, smp_mb() should be added to keep coherency.
Signed-off-by: Steven Miao <realmz6@gmail.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Kernel common code will enable irq, drop it in init_arch_irq().
Signed-off-by: Steven Miao <realmz6@gmail.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
This patch fixes an assumption that cclk's initial divisor will always be 1 (or
0 in the register). TSCALE is always initialized on startup with a value of 4
regardless of the inital cclk divisor; so, we can't make the assumption without
making lots of other assumptions. The TPERIOD value is set with a value of the
current cclk (value / (HZ * TSCALE)) - 1; so, we need to adjust based on this
initial frequency and not use cclk's initial divisor for adjusting the tscale.
Signed-off-by: Steven Miao <realmz6@gmail.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Lq035 fb driver uses KBUILD_MODNAME which is bf537_lq035 instead of
bf537-lq035.
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
This board has a JEDEC ST PSD4256G6V flash device, so enable all the
options needed so it gets probed by default.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Add a crypto key parser for binary (DER) encoded X.509 certificates. The
certificate is parsed and, if possible, the signature is verified.
An X.509 key can be added like this:
# keyctl padd crypto bar @s </tmp/x509.cert
15768135
and displayed like this:
# cat /proc/keys
00f09a47 I--Q--- 1 perm 39390000 0 0 asymmetri bar: X509.RSA e9fd6d08 []
Note that this only works with binary certificates. PEM encoded certificates
are ignored by the parser.
Note also that the X.509 key ID is not congruent with the PGP key ID, but for
the moment, they will match.
If a NULL or "" name is given to add_key(), then the parser will generate a key
description from the CertificateSerialNumber and Name fields of the
TBSCertificate:
00aefc4e I--Q--- 1 perm 39390000 0 0 asymmetri bfbc0cd76d050ea4:/C=GB/L=Cambridge/O=Red Hat/CN=kernel key: X509.RSA 0c688c7b []
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Provide a function to read raw data of a predetermined size into an MPI rather
than expecting the size to be encoded within the data. The data is assumed to
represent an unsigned integer, and the resulting MPI will be positive.
The function looks like this:
MPI mpi_read_raw_data(const void *, size_t);
This is useful for reading ASN.1 integer primitives where the length is encoded
in the ASN.1 metadata.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add an ASN.1 BER/DER/CER decoder. This uses the bytecode from the ASN.1
compiler in the previous patch to inform it as to what to expect to find in the
encoded byte stream. The output from the compiler also tells it what functions
to call on what tags, thus allowing the caller to retrieve information.
The decoder is called as follows:
int asn1_decoder(const struct asn1_decoder *decoder,
void *context,
const unsigned char *data,
size_t datalen);
The decoder argument points to the bytecode from the ASN.1 compiler. context
is the caller's context and is passed to the action functions. data and
datalen define the byte stream to be decoded.
Note that the decoder is currently limited to datalen being less than 64K.
This reduces the amount of stack space used by the decoder because ASN.1 is a
nested construct. Similarly, the decoder is limited to a maximum of 10 levels
of constructed data outside of a leaf node also in an effort to keep stack
usage down.
These restrictions can be raised if necessary.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add a simple ASN.1 grammar compiler. This produces a bytecode output that can
be fed to a decoder to inform the decoder how to interpret the ASN.1 stream it
is trying to parse.
Action functions can be specified in the grammar by interpolating:
({ foo })
after a type, for example:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING ({ do_key_data })
}
The decoder is expected to call these after matching this type and parsing the
contents if it is a constructed type.
The grammar compiler does not currently support the SET type (though it does
support SET OF) as I can't see a good way of tracking which members have been
encountered yet without using up extra stack space.
Currently, the grammar compiler will fail if more than 256 bytes of bytecode
would be produced or more than 256 actions have been specified as it uses
8-bit jump values and action indices to keep space usage down.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add a pair of utility functions to render OIDs as strings. The first takes an
encoded OID and turns it into a "a.b.c.d" form string:
int sprint_oid(const void *data, size_t datasize,
char *buffer, size_t bufsize);
The second takes an OID enum index and calls the first on the data held
therein:
int sprint_OID(enum OID oid, char *buffer, size_t bufsize);
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Implement a simple static OID registry that allows the mapping of an encoded
OID to an enum value for ease of use.
The OID registry index enum appears in the:
linux/oid_registry.h
header file. A script generates the registry from lines in the header file
that look like:
<sp*>OID_foo,<sp*>/*<sp*>1.2.3.4<sp*>*/
The actual OID is taken to be represented by the numbers with interpolated
dots in the comment.
All other lines in the header are ignored.
The registry is queries by calling:
OID look_up_oid(const void *data, size_t datasize);
This returns a number from the registry enum representing the OID if found or
OID__NR if not.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
gpg can produce a signature file where length of signature is less than the
modulus size because the amount of space an MPI takes up is kept as low as
possible by discarding leading zeros. This regularly happens for several
modules during the build.
Fix it by relaxing check in RSA verification code.
Thanks to Tomas Mraz and Miloslav Trmac for help.
Signed-off-by: Milan Broz <mbroz@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Implement RSA public key cryptography [PKCS#1 / RFC3447]. At this time, only
the signature verification algorithm is supported. This uses the asymmetric
public key subtype to hold its key data.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
