* [PATCH 07/14] crypto: caam - remove unused command from aead givencrypt
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
REG3 no longer needs to be updated, since it's not used after that.
This shared descriptor command is a leftover of the conversion to
AEAD interface.
Fixes: 479bcc7c5b9e1 "crypto: caam - Convert authenc to new AEAD interface"
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caamalg.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index cb26a57c5aaf..1982dacce80e 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -75,7 +75,7 @@
#define DESC_AEAD_BASE (4 * CAAM_CMD_SZ)
#define DESC_AEAD_ENC_LEN (DESC_AEAD_BASE + 11 * CAAM_CMD_SZ)
#define DESC_AEAD_DEC_LEN (DESC_AEAD_BASE + 15 * CAAM_CMD_SZ)
-#define DESC_AEAD_GIVENC_LEN (DESC_AEAD_ENC_LEN + 9 * CAAM_CMD_SZ)
+#define DESC_AEAD_GIVENC_LEN (DESC_AEAD_ENC_LEN + 7 * CAAM_CMD_SZ)
/* Note: Nonce is counted in enckeylen */
#define DESC_AEAD_CTR_RFC3686_LEN (4 * CAAM_CMD_SZ)
@@ -697,9 +697,6 @@ static int aead_set_sh_desc(struct crypto_aead *aead)
append_math_add(desc, VARSEQINLEN, ZERO, REG3, CAAM_CMD_SZ);
append_math_add(desc, VARSEQOUTLEN, ZERO, REG3, CAAM_CMD_SZ);
- /* ivsize + cryptlen = seqoutlen - authsize */
- append_math_sub_imm_u32(desc, REG3, SEQOUTLEN, IMM, ctx->authsize);
-
/* Skip assoc data */
append_seq_fifo_store(desc, 0, FIFOST_TYPE_SKIP | FIFOLDST_VLF);
--
2.4.4
^ permalink raw reply related
* [PATCH 05/14] crypto: caam - fix smatch warnings
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
Fix the following smatch warnings:
drivers/crypto/caam/caamalg.c:2350 aead_edesc_alloc() warn: we tested 'src_nents' before and it was 'true'
drivers/crypto/caam/caamrng.c:351 caam_rng_init() error: no modifiers for allocation.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caamalg.c | 4 +---
drivers/crypto/caam/caamrng.c | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 5317d8cad44d..bc433edd34c4 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -2346,10 +2346,8 @@ static struct aead_edesc *aead_edesc_alloc(struct aead_request *req,
/* Check if data are contiguous. */
all_contig = !src_nents;
- if (!all_contig) {
- src_nents = src_nents ? : 1;
+ if (!all_contig)
sec4_sg_len = src_nents;
- }
sec4_sg_len += dst_nents;
diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index bb1c118b2d1b..38bb2411afcf 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -348,7 +348,7 @@ static int __init caam_rng_init(void)
pr_err("Job Ring Device allocation for transform failed\n");
return PTR_ERR(dev);
}
- rng_ctx = kmalloc(sizeof(*rng_ctx), GFP_DMA);
+ rng_ctx = kmalloc(sizeof(*rng_ctx), GFP_DMA | GFP_KERNEL);
if (!rng_ctx) {
err = -ENOMEM;
goto free_caam_alloc;
--
2.4.4
^ permalink raw reply related
* Re: [PATCH nft] segtree: keep element comments in set intervals
From: Arturo Borrero Gonzalez @ 2016-11-09 9:20 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Netfilter Development Mailing list, netfilter
In-Reply-To: <1478647185-25289-1-git-send-email-pablo@netfilter.org>
On 9 November 2016 at 00:19, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> The conversion from the set element range representation to element
> intervals doesn't keep the comment information around.
>
> Fixes: https://bugzilla.netfilter.org/show_bug.cgi?id=1090
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
> src/segtree.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
Hi,
just tested this patch before/after, and it really works.
Tested-by: Arturo Borrero Gonzalez <arturo@debian.org>
I think we can add some testcase to catch possible regressions. Will
send a patch.
^ permalink raw reply
* [PATCH 06/14] crypto: caam - remove unused may_sleep in dbg_dump_sg()
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
Fixes: 5ecf8ef9103cb "crypto: caam - fix sg dump"
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caamalg.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index bc433edd34c4..cb26a57c5aaf 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -117,8 +117,7 @@
static void dbg_dump_sg(const char *level, const char *prefix_str,
int prefix_type, int rowsize, int groupsize,
- struct scatterlist *sg, size_t tlen, bool ascii,
- bool may_sleep)
+ struct scatterlist *sg, size_t tlen, bool ascii)
{
struct scatterlist *it;
void *it_page;
@@ -2033,7 +2032,7 @@ static void ablkcipher_encrypt_done(struct device *jrdev, u32 *desc, u32 err,
edesc->src_nents > 1 ? 100 : ivsize, 1);
dbg_dump_sg(KERN_ERR, "dst @"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->dst,
- edesc->dst_nents > 1 ? 100 : req->nbytes, 1, true);
+ edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
#endif
ablkcipher_unmap(jrdev, edesc, req);
@@ -2065,7 +2064,7 @@ static void ablkcipher_decrypt_done(struct device *jrdev, u32 *desc, u32 err,
ivsize, 1);
dbg_dump_sg(KERN_ERR, "dst @"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->dst,
- edesc->dst_nents > 1 ? 100 : req->nbytes, 1, true);
+ edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
#endif
ablkcipher_unmap(jrdev, edesc, req);
@@ -2220,15 +2219,13 @@ static void init_ablkcipher_job(u32 *sh_desc, dma_addr_t ptr,
int len, sec4_sg_index = 0;
#ifdef DEBUG
- bool may_sleep = ((req->base.flags & (CRYPTO_TFM_REQ_MAY_BACKLOG |
- CRYPTO_TFM_REQ_MAY_SLEEP)) != 0);
print_hex_dump(KERN_ERR, "presciv@"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->info,
ivsize, 1);
printk(KERN_ERR "asked=%d, nbytes%d\n", (int)edesc->src_nents ? 100 : req->nbytes, req->nbytes);
dbg_dump_sg(KERN_ERR, "src @"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->src,
- edesc->src_nents ? 100 : req->nbytes, 1, may_sleep);
+ edesc->src_nents ? 100 : req->nbytes, 1);
#endif
len = desc_len(sh_desc);
@@ -2280,14 +2277,12 @@ static void init_ablkcipher_giv_job(u32 *sh_desc, dma_addr_t ptr,
int len, sec4_sg_index = 0;
#ifdef DEBUG
- bool may_sleep = ((req->base.flags & (CRYPTO_TFM_REQ_MAY_BACKLOG |
- CRYPTO_TFM_REQ_MAY_SLEEP)) != 0);
print_hex_dump(KERN_ERR, "presciv@" __stringify(__LINE__) ": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->info,
ivsize, 1);
dbg_dump_sg(KERN_ERR, "src @" __stringify(__LINE__) ": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->src,
- edesc->src_nents ? 100 : req->nbytes, 1, may_sleep);
+ edesc->src_nents ? 100 : req->nbytes, 1);
#endif
len = desc_len(sh_desc);
@@ -2556,11 +2551,9 @@ static int aead_decrypt(struct aead_request *req)
int ret = 0;
#ifdef DEBUG
- bool may_sleep = ((req->base.flags & (CRYPTO_TFM_REQ_MAY_BACKLOG |
- CRYPTO_TFM_REQ_MAY_SLEEP)) != 0);
dbg_dump_sg(KERN_ERR, "dec src@"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->src,
- req->assoclen + req->cryptlen, 1, may_sleep);
+ req->assoclen + req->cryptlen, 1);
#endif
/* allocate extended descriptor */
--
2.4.4
^ permalink raw reply related
* [PATCH 08/14] crypto: caam - trivial code clean-up
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
-replace offsetof with container_of
-remove unused "assoc_nents", "iv_dma" from aead_edesc
and fix comments
-remove unused CAAM_MAX_IV_LENGTH #define
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caamalg.c | 16 ++++------------
drivers/crypto/caam/caamhash.c | 12 ++++--------
drivers/crypto/caam/caamrng.c | 3 +--
3 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 1982dacce80e..34dfcdb7ff84 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -62,8 +62,6 @@
#define CAAM_MAX_KEY_SIZE (AES_MAX_KEY_SIZE + \
CTR_RFC3686_NONCE_SIZE + \
SHA512_DIGEST_SIZE * 2)
-/* max IV is max of AES_BLOCK_SIZE, DES3_EDE_BLOCK_SIZE */
-#define CAAM_MAX_IV_LENGTH 16
#define AEAD_DESC_JOB_IO_LEN (DESC_JOB_IO_LEN + CAAM_CMD_SZ * 2)
#define GCM_DESC_JOB_IO_LEN (AEAD_DESC_JOB_IO_LEN + \
@@ -1873,20 +1871,16 @@ static int xts_ablkcipher_setkey(struct crypto_ablkcipher *ablkcipher,
/*
* aead_edesc - s/w-extended aead descriptor
- * @assoc_nents: number of segments in associated data (SPI+Seq) scatterlist
* @src_nents: number of segments in input scatterlist
* @dst_nents: number of segments in output scatterlist
- * @iv_dma: dma address of iv for checking continuity and link table
- * @desc: h/w descriptor (variable length; must not exceed MAX_CAAM_DESCSIZE)
* @sec4_sg_bytes: length of dma mapped sec4_sg space
* @sec4_sg_dma: bus physical mapped address of h/w link table
+ * @sec4_sg: pointer to h/w link table
* @hw_desc: the h/w job descriptor followed by any referenced link tables
*/
struct aead_edesc {
- int assoc_nents;
int src_nents;
int dst_nents;
- dma_addr_t iv_dma;
int sec4_sg_bytes;
dma_addr_t sec4_sg_dma;
struct sec4_sg_entry *sec4_sg;
@@ -1898,9 +1892,9 @@ struct aead_edesc {
* @src_nents: number of segments in input scatterlist
* @dst_nents: number of segments in output scatterlist
* @iv_dma: dma address of iv for checking continuity and link table
- * @desc: h/w descriptor (variable length; must not exceed MAX_CAAM_DESCSIZE)
* @sec4_sg_bytes: length of dma mapped sec4_sg space
* @sec4_sg_dma: bus physical mapped address of h/w link table
+ * @sec4_sg: pointer to h/w link table
* @hw_desc: the h/w job descriptor followed by any referenced link tables
*/
struct ablkcipher_edesc {
@@ -2017,8 +2011,7 @@ static void ablkcipher_encrypt_done(struct device *jrdev, u32 *desc, u32 err,
dev_err(jrdev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
#endif
- edesc = (struct ablkcipher_edesc *)((char *)desc -
- offsetof(struct ablkcipher_edesc, hw_desc));
+ edesc = container_of(desc, struct ablkcipher_edesc, hw_desc[0]);
if (err)
caam_jr_strstatus(jrdev, err);
@@ -2050,8 +2043,7 @@ static void ablkcipher_decrypt_done(struct device *jrdev, u32 *desc, u32 err,
dev_err(jrdev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
#endif
- edesc = (struct ablkcipher_edesc *)((char *)desc -
- offsetof(struct ablkcipher_edesc, hw_desc));
+ edesc = container_of(desc, struct ablkcipher_edesc, hw_desc[0]);
if (err)
caam_jr_strstatus(jrdev, err);
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 51990dd56024..d5a06c6923c0 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -636,8 +636,7 @@ static void ahash_done(struct device *jrdev, u32 *desc, u32 err,
dev_err(jrdev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
#endif
- edesc = (struct ahash_edesc *)((char *)desc -
- offsetof(struct ahash_edesc, hw_desc));
+ edesc = container_of(desc, struct ahash_edesc, hw_desc[0]);
if (err)
caam_jr_strstatus(jrdev, err);
@@ -671,8 +670,7 @@ static void ahash_done_bi(struct device *jrdev, u32 *desc, u32 err,
dev_err(jrdev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
#endif
- edesc = (struct ahash_edesc *)((char *)desc -
- offsetof(struct ahash_edesc, hw_desc));
+ edesc = container_of(desc, struct ahash_edesc, hw_desc[0]);
if (err)
caam_jr_strstatus(jrdev, err);
@@ -706,8 +704,7 @@ static void ahash_done_ctx_src(struct device *jrdev, u32 *desc, u32 err,
dev_err(jrdev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
#endif
- edesc = (struct ahash_edesc *)((char *)desc -
- offsetof(struct ahash_edesc, hw_desc));
+ edesc = container_of(desc, struct ahash_edesc, hw_desc[0]);
if (err)
caam_jr_strstatus(jrdev, err);
@@ -741,8 +738,7 @@ static void ahash_done_ctx_dst(struct device *jrdev, u32 *desc, u32 err,
dev_err(jrdev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
#endif
- edesc = (struct ahash_edesc *)((char *)desc -
- offsetof(struct ahash_edesc, hw_desc));
+ edesc = container_of(desc, struct ahash_edesc, hw_desc[0]);
if (err)
caam_jr_strstatus(jrdev, err);
diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index 38bb2411afcf..41398da3edf4 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -100,8 +100,7 @@ static void rng_done(struct device *jrdev, u32 *desc, u32 err, void *context)
{
struct buf_data *bd;
- bd = (struct buf_data *)((char *)desc -
- offsetof(struct buf_data, hw_desc));
+ bd = container_of(desc, struct buf_data, hw_desc[0]);
if (err)
caam_jr_strstatus(jrdev, err);
--
2.4.4
^ permalink raw reply related
* Re: [PATCH] gcov: support GCC 7.1
From: Peter Oberparleiter @ 2016-11-09 9:21 UTC (permalink / raw)
To: Martin Liška; +Cc: lkml
In-Reply-To: <8c4084fa-3885-29fe-5fc4-0d4ca199c785@suse.cz>
On 31.10.2016 10:35, Martin Liška wrote:
> Starting from GCC 7.1, __gcov_exit is a new symbol expected
> to be implemented in a profiling runtime.
I tested your patch with kernel 4.9-rc4 compiled with GCC 7.0.0 20161107
(experimental) and validated that it fixes the build error due to a
missing __gcov_exit symbol.
An attempt to read from one of the .gcda files generated by a kernel
compiled this way resulted in a crash though. It appears that the number
of GCOV_COUNTERS has changed again for GCC 7.x and must be adjusted in
the kernel as well. Could you add that to your patch as well?
Given that GCC 7.1 has not yet been released, I'm wondering if it is
safe to program against interfaces that have not yet been fully
finalized. Can you provide an indication on whether these gcov-related
aspects of GCC might still be changed until release?
As a side note, please post your patches inline instead of as attachment
as that helps quoting them in replies. See also
linux/Documentation/SubmittingPatches.
--
Peter Oberparleiter
Linux on z Systems Development - IBM Germany
^ permalink raw reply
* [U-Boot] [PATCH] tools/kwbimage: add DEBUG option
From: Chris Packham @ 2016-11-09 9:21 UTC (permalink / raw)
To: u-boot
Offset 0x1 in the generated kwb image file is a set of flags, bit 0
enables debug output from the BootROM firmware. Allow a DEBUG option in
the kwb configuration to request debug output from the BootROM firmware.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
tools/kwbimage.c | 9 +++++++++
tools/kwbimage.h | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index ad182c5c5d9a..69844d916965 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -69,6 +69,7 @@ struct image_cfg_element {
IMAGE_CFG_PAYLOAD,
IMAGE_CFG_DATA,
IMAGE_CFG_BAUDRATE,
+ IMAGE_CFG_DEBUG,
} type;
union {
unsigned int version;
@@ -87,6 +88,7 @@ struct image_cfg_element {
unsigned int nandpagesz;
struct ext_hdr_v0_reg regdata;
unsigned int baudrate;
+ unsigned int debug;
};
};
@@ -425,6 +427,9 @@ static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
e = image_find_option(IMAGE_CFG_BAUDRATE);
if (e)
main_hdr->options = baudrate_to_option(e->baudrate);
+ e = image_find_option(IMAGE_CFG_DEBUG);
+ if (e)
+ main_hdr->flags = e->debug ? 0x1 : 0;
binarye = image_find_option(IMAGE_CFG_BINARY);
if (binarye) {
@@ -579,6 +584,10 @@ static int image_create_config_parse_oneline(char *line,
char *value = strtok_r(NULL, deliminiters, &saveptr);
el->type = IMAGE_CFG_BAUDRATE;
el->baudrate = strtoul(value, NULL, 10);
+ } else if (!strcmp(keyword, "DEBUG")) {
+ char *value = strtok_r(NULL, deliminiters, &saveptr);
+ el->type = IMAGE_CFG_DEBUG;
+ el->debug = strtoul(value, NULL, 10);
} else {
fprintf(stderr, "Ignoring unknown line '%s'\n", line);
}
diff --git a/tools/kwbimage.h b/tools/kwbimage.h
index 9b06004a0b10..01c2f1f3238b 100644
--- a/tools/kwbimage.h
+++ b/tools/kwbimage.h
@@ -73,7 +73,7 @@ struct kwb_header {
/* Structure of the main header, version 1 (Armada 370, Armada XP) */
struct main_hdr_v1 {
uint8_t blockid; /* 0 */
- uint8_t reserved1; /* 1 */
+ uint8_t flags; /* 1 */
uint16_t reserved2; /* 2-3 */
uint32_t blocksize; /* 4-7 */
uint8_t version; /* 8 */
--
2.10.2
^ permalink raw reply related
* [U-Boot] [RFC PATCH 00/10] sunxi: Allwinner A64 SPL support
From: Andre Przywara @ 2016-11-09 9:21 UTC (permalink / raw)
To: u-boot
In-Reply-To: <0ad15ac6-7f93-ede3-3936-ee42995bc0d9@arm.com>
Hi,
On 03/11/16 09:38, Andre Przywara wrote:
> Hi,
>
> On 03/11/16 08:49, Alexander Graf wrote:
>> On 11/03/2016 02:36 AM, Andre Przywara wrote:
>>> Hi,
>>>
>>> this is my first take on the SPL support for the Allwinner A64 SoC.
>>> The actual meat - the DRAM initialization code - has been provided
>>> by Jens - many thanks for that!
>>> The rest of the patches mostly deal with the 32-bit/64-bit switch.
>>>
>>> While it is possible and seems natural to let the SPL also run in 64-bit,
>>> this creates a really large binary (32600 Bytes in my case). With some
>>> hacks (plus some fixes to make the SPL 64-bit safe) I got this to work,
>>
>> So how about we merge the 64bit version first (since that's *way* easier
>> to compile for everyone) and then consider the move to 32bit afterwards?
>
> Mmmh, interesting idea, may be worth a try alone for the sake of the
> 64-bit fixes to the SPL code I have done in this process.
> But I am not sure it doesn't already break for people using just a
> different compiler. I even started to chop of some bytes here and there
> to bring the size down (I gained 200 Bytes at the ctype implementation,
> yeah!)
>
>> I don't even want to start to imagine how to squeeze a 32bit SPL build
>> into the build process for our U-Boot binaries.
>
> I totally agree, even for me it's quite a pain, because a "make clean"
> (which you need in between) removes the build result of that other
> bitness, so you always have to remember to copy the binaries first (and
> then up using stale copies afterwards).
>
>>> but any addition will probably break it and exceed the 32KB limit that
>>> the BROM imposes. Debug is the first obvious victim here.
>>
>> Do you have some section size comparisons between the two?
>
> I spent some time into looking at readelf dumps to find the reason for
> the bigger size, but nothing really stood out. Still it is a bit odd,
> since the size ratio for U-Boot proper is much better (like +20% for
> 64-bit).
> A promising approach I then tried was to use -mabi=ilp32, which GCC
> itself supports for quite a while already. But that was running into
> ICEs, with no obviously bogus code. If someone more compiler-savvy could
> take a look later, I'd be grateful.
>
> That being said I will try to revive the AArch64 port tonight and push
> this somewhere, so that people can have a look.
Just a quick update: The 64-bit SPL patches were in a worse state than I
originally thought and I failed to resurrect them quickly again.
After spending some hours with debugging (the old way via writing to SD
cards) I discovered that there is apparently a regression in 2016.11-rc3
over the 2016.09 release with respect to these patches.
So my old 64-bit SPL patches work in the branch which is on top of
2016.09, but break after rebasing them to 2016.11-rc3. I now managed to
squash these patches in between the two releases, so I should be able to
bisect them later tonight. I keep you posted.
Cheers,
Andre.
^ permalink raw reply
* [PATCH 14/14] crypto: caam - merge identical ahash_final/finup shared desc
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
Shared descriptors used by ahash_final() and ahash_finup()
are identical, thus get rid of one of them (sh_desc_finup).
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caamhash.c | 26 +-------------------------
1 file changed, 1 insertion(+), 25 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index d5a06c6923c0..86f360853502 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -103,12 +103,10 @@ struct caam_hash_ctx {
u32 sh_desc_update_first[DESC_HASH_MAX_USED_LEN] ____cacheline_aligned;
u32 sh_desc_fin[DESC_HASH_MAX_USED_LEN] ____cacheline_aligned;
u32 sh_desc_digest[DESC_HASH_MAX_USED_LEN] ____cacheline_aligned;
- u32 sh_desc_finup[DESC_HASH_MAX_USED_LEN] ____cacheline_aligned;
dma_addr_t sh_desc_update_dma ____cacheline_aligned;
dma_addr_t sh_desc_update_first_dma;
dma_addr_t sh_desc_fin_dma;
dma_addr_t sh_desc_digest_dma;
- dma_addr_t sh_desc_finup_dma;
struct device *jrdev;
u32 alg_type;
u32 alg_op;
@@ -380,24 +378,6 @@ static int ahash_set_sh_desc(struct crypto_ahash *ahash)
desc_bytes(desc), 1);
#endif
- /* ahash_finup shared descriptor */
- desc = ctx->sh_desc_finup;
-
- ahash_ctx_data_to_out(desc, have_key | ctx->alg_type,
- OP_ALG_AS_FINALIZE, digestsize, ctx);
-
- ctx->sh_desc_finup_dma = dma_map_single(jrdev, desc, desc_bytes(desc),
- DMA_TO_DEVICE);
- if (dma_mapping_error(jrdev, ctx->sh_desc_finup_dma)) {
- dev_err(jrdev, "unable to map shared descriptor\n");
- return -ENOMEM;
- }
-#ifdef DEBUG
- print_hex_dump(KERN_ERR, "ahash finup shdesc@"__stringify(__LINE__)": ",
- DUMP_PREFIX_ADDRESS, 16, 4, desc,
- desc_bytes(desc), 1);
-#endif
-
/* ahash_digest shared descriptor */
desc = ctx->sh_desc_digest;
@@ -1071,7 +1051,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
/* allocate space for base edesc and hw desc commands, link tables */
edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index + mapped_nents,
- ctx->sh_desc_finup, ctx->sh_desc_finup_dma,
+ ctx->sh_desc_fin, ctx->sh_desc_fin_dma,
flags);
if (!edesc) {
dma_unmap_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
@@ -1886,10 +1866,6 @@ static void caam_hash_cra_exit(struct crypto_tfm *tfm)
dma_unmap_single(ctx->jrdev, ctx->sh_desc_digest_dma,
desc_bytes(ctx->sh_desc_digest),
DMA_TO_DEVICE);
- if (ctx->sh_desc_finup_dma &&
- !dma_mapping_error(ctx->jrdev, ctx->sh_desc_finup_dma))
- dma_unmap_single(ctx->jrdev, ctx->sh_desc_finup_dma,
- desc_bytes(ctx->sh_desc_finup), DMA_TO_DEVICE);
caam_jr_free(ctx->jrdev);
}
--
2.4.4
^ permalink raw reply related
* Re: [RFC] fs: add userspace critical mounts event support
From: Daniel Wagner @ 2016-11-09 9:13 UTC (permalink / raw)
To: Luis R. Rodriguez, Linus Torvalds, Jiri Kosina, Johannes Berg,
Jouni Malinen, Seth Forshee, Tom Gundersen, Kay Sievers,
Bjorn Andersson, Daniel Wagner, Rafael J. Wysocki
Cc: Herbert, Marc, Daniel Vetter, Rob Landley, Mimi Zohar,
Felix Fietkau, David Woodhouse, Roman Pen, Ming Lei,
Andrew Morton, Michal Marek, Greg KH, Linux Kernel Mailing List,
Vikram Mulukutla, Stephen Boyd, Mark Brown, Takashi Iwai,
Christian Lamparter, Hauke Mehrtens, Josh Boyer, Dmitry Torokhov,
Jiri Slaby, Andy Lutomirski, Wu Fengguang, Richard Purdie,
Jeff Mahoney, Jacek Anaszewski, Abhay_Salunke, Julia Lawall,
Gilles.Muller, nicolas.palix, David Howells, Alessandro Rubini,
Kevin Cernekee, Kees Cook, Jonathan Corbet, Thierry Martinez,
linux-serial, open list:DOCUMENTATION, linuxppc-dev,
Josh Triplett, Harald Hoyer
In-Reply-To: <20161108224726.GD13978@wotan.suse.de>
[CC: added Harald]
On 11/08/2016 11:47 PM, Luis R. Rodriguez wrote:
> On Wed, Oct 05, 2016 at 09:46:33PM +0200, Luis R. Rodriguez wrote:
>> On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote:
>>> On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>>>> On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote:
>>>>
>>>>> I did some shuffling around of those code to make initmpfs work, does
>>>>> anybody know why initramfs extraction _before_ we initialize drivers
>>>>> would be a bad thing?
>>>>
>>>> No, but it seems sensible to me, if its done before do_initcalls()
>>>> that should resolve the race for initramfs users
>>>
>>> initramfs should already be set up before drivers are.
>>
>> Actually you are right, the issue would only be for old initrd, for initramfs
>> we populate that via rootfs_initcall(populate_rootfs), so as long as drivers
>> in question use an init level beyond rootfs's we're good there.
>>
>>> Exactly what is it that has trouble right now?
>>
>> It would seem then that the only current stated race possible should
>> then be non-initramfs users.
>
> Or:
>
> a) initramfs users that include a driver but do not include the firmware
> into initramfs
>
> b) driver is built-in but firmware is not in initrafms (Johannes reports
> this causes driver failure on intel wireless for instance, and I guess
> you need to reload)
>
>> One example if very large firmware for
>> remote-proc, whereby an initramfs is just not practical or desirable.
>
> This issue still stands. At Plumbers Johannes Berg did indicate to me
> he had a simple elegant solution in mind. He suggested that since the
> usermode helper was available, he had added support to be able to
> differentiate async firmware request calls form sync requests, and that
> userspace should not return an error *iff* the request made was async and
> it can determine we're initramfs. The semantics issue is the same though,
> is there a generic way to determine we're initramfs ? What if we move
> multiple levels? Anyway -- provided we could figure this out, userspace
> would simply yield and wait until the real rootfs is met. Upon pivot_root()
> the assumption is all previous udev events pending would be re-triggered
> and finally udev could finally confirm/deny if the firmware was present.
> This would *also* allow you to stuff your firmware whever, however big
> it was. This however relied on the userspace firmware loading support,
> it turns out that (I think because of an incorrect negative backlash
> back in the day over blaming this over booting issues due to the timeout
> whereas the real issue was the kmod timeout was affecting our long
> standing serial init()/probe()) the systemd userspace firmware laoding
> support was removed from systemd udev in 2014 by Kay via commit
> be2ea723b1d023b3d ("udev: remove userspace firmware loading support").
>
> Systemd might *still* be able to provide a solution here, however I will
> note Johannes was asking for *all* async firmware requests to always
> rely on the kernel syfs UMH fallback -- this suggestion is against the
> direction we've been taking to eventually compartamentalize the kernel UMH
> code, so whatever we decide to do, lets please take a breather and seriously
> address this properly *with* systemd folks.
>
> A side race discussed at Plumbers worth mentioning given its related to the
> UMH was inspired by Jiri's talk on the abuse of the freezer for kthreads --
> and his suggestion to use freeze_super(). Currently the UMH lock is used
> for the UMH but as I have noted in Daniel Wagner's recent patches to
> give some love to this code and further compartamentalize the UMH --
> the UMH lock was originally added to help avoid drivers use the firmware
> API on resume, given the races. The firmware cache solution implemented by
> Ming Lei years ago helped address this, whereby devm helpers are used
> based on the requested firmware and prior to suspend we cache all required
> firmware for drivers so that upon resume calls would work without the
> effective race present. This mitigated the actual races / issues with
> drivers, but they must not use the firmware API on suspend/resume. Since
> this solution *kills* all pending UMH caller on suspend obviously this
> means on suspend using request_firmware*() API and expecting it to work
> is brutally dumb as we will eventually kill any pending requests. This
> is a long winded way to say that if you rely on the UMH for firmware
> you must figure out your own proactive firmware cache solution and
> must definitely not request firmware on suspend. Two things then:
>
> 1) I've been brainstorming with Daniel how to use freeze_super() to
> replace the now invalid UMH lock -- its purpose only helps races
> on boot, for the fallback case to the UMH. But note most distributions
> disable forcing it always on, so these days we *only* rely on the UMH
> as a fallback if the driver explicitly requested it
>
> 2) Drivers relying on the UMH very likely have a broken cache solution
> if they are doing this on suspend
>
> Whatever the outcome of this discussion is -- Johannes seemed to *want*
> to further use the UMH by default on *all* async alls... even if the
> driver did not explicitly requested it -- I'm concerned about this given
> all the above and the existing flip/flop on systemd for it. Whatever
> we try to dream up here, please consider all the above as well.
As Harald pointed out over a beer yesterday evening, there is at least
one more reason why UMH isn't obsolete. The ordering of the firmware
loading might be of important. Say you want to greet the user with a
splash screen really early on, the graphic card firmware should be
loaded first. Also the automotive world has this fancy requirement that
rear camera must be on the screen within 2 seconds. So controlling the
firmware loading order is of importance (e.g. also do not overcommit the
I/O bandwith not so important firmwares). A user space helper is able to
prioritize the request accordingly the use case.
>>> The gating issue for initramfs is that technically the filesystem
>>> setup needs to be done, which means that it currently ends up being
>>> populated _fairly_ late in the initcall series, but certainly before
>>> drivers. But since initramfs really only needs very limited filesystem
>>> functionality, I assume Rob had few problems with just moving it
>>> earlier.
>>>
>>> Still, what kind of ordering issues did people have? What is it that
>>> needs to load files even before driver init? Some crazy subsystem?
>>
>> No, I think this is just about non-initramfs users now,
>
> And as Johannes pointed two above to cases.
>
>> if we disregard
>> old initrd users. Bjorn, Marc, correct me if I'm wrong, as I think its
>> so far you both who have seemed to run into race issues and have then
>> ended up trying to look for hacks to address this race or considered using
>> the usermode helper (which we're trying to minimize users for). Daniel
>> seems to note a lot of video drivers use firmware on probe as well so
>> there's a potential issue for those users if they don't use initramfs.
Daniel
^ permalink raw reply
* Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes
From: Duy Nguyen @ 2016-11-09 9:22 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20161108222127.mejb74maewzhn3qg@sigill.intra.peff.net>
On Wed, Nov 9, 2016 at 5:21 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 08, 2016 at 08:38:55AM +0700, Duy Nguyen wrote:
>
>> > Another approach is to have a config option to disallow symlinks to
>> > destinations outside of the repository tree (I'm not sure if it should
>> > be on or off by default, though).
>>
>> Let's err on the safe side and disable symlinks to outside repo by
>> default (or even all symlinks on .gitattributes and .gitignore as the
>> first step)
>
> Both of those are actually much harder than you might think.
>
> For matching specific names, we have to deal with case-folding. It's
> easy to hit the common ones like ".GITIGNORE" with fspathcmp(). But if
> this is actually protection against malicious repositories, we have to
> match all of the horrible filesystem-specific junk that we did for
> ".git".
We could realpath() it and check if the result path is inside
realpath($GIT_WORK_TREE). The real work would be done by OS. We will
need to check if it points to .git/something, but I think we have that
covered. The approach is a bit heavy for such a sanity check though
> Symlinks are likewise tricky. If we see that a symlink points to
> "foo/../bar", then we don't know if it leaves the repository unless we
> also look at "foo" to see if it is also a symlink. So you really end up
> having to resolve the symlink yourself (and when checking out multiple
> files, there's an ordering dependency).
We do have this dependency problem right now (e.g. files A and
.gitattributes are checked out at the same time and .gitattributes has
some attribute on A). It looks like we resolve it by reading the index
version at checkout time. We probably can do the same for gitattribute
symlinks.
> I think it might be enough to check:
>
> - leading "../" tokens in the symlink's destination can be checked
> against the symlink's path. So "../foo" is OK for path "one/two",
> but not for path "one".
>
> - interior "../" can be disallowed entirely. Technically
> "foo/../bar/../baz" _can_ be a fine symlink destination, but why?
> It's identical to "baz" unless you are following a bunch of interior
> symlinks. And if those are interior symlinks, it's still confusing
> and unnecessarily obfuscated, and a good sign that somebody is
> trying to do something tricky.
Sounds good.
> So one reasonable fix might be to have a config option like
> "core.saneSymlinks" that enforces both of those rules for _all_ symlinks
> that we checkout to the working tree. And it could either refuse to
> check them out, or replace them with a file containing the symlink
> content (as we do on systems that don't support symlinks, IIRC).
I wonder if anyone want core.saneSymlinks on, but they have some links
that do not meet the above checks and still want to follow them
anyway. One way to add such an exception is mark the path with an
attribute "follow". Yeah I have a dependency loop :(
--
Duy
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Markus Heiser @ 2016-11-09 9:22 UTC (permalink / raw)
To: Josh Triplett
Cc: ksummit-discuss, linux-doc, linux-kernel, Mauro Carvalho Chehab,
linux-media
In-Reply-To: <20161107170133.4jdeuqydthbbchaq@x>
Am 07.11.2016 um 18:01 schrieb Josh Triplett <josh@joshtriplett.org>:
> On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote:
>> 2) add an Sphinx extension that would internally call ImageMagick and/or
>> inkscape to convert the bitmap;
>
> This seems sensible; Sphinx should directly handle the source format we
> want to use for images/diagrams.
>
>> 3) if possible, add an extension to trick Sphinx for it to consider the
>> output dir as a source dir too.
>
> Or to provide an additional source path and point that at the output
> directory.
The sphinx-build command excepts only one 'sourcedir' argument. All
reST files in this folder (and below) are parsed.
Most (all?) directives which include content like images or literalinclude
except only relative pathnames. Where *relative* means, relative to the
reST file where the directive is used. For security reasons relative
pathnames outside 'sourcepath' are not excepted.
So I vote for :
> 1) copy (or symlink) all rst files to Documentation/output (or to the
> build dir specified via O= directive) and generate the *.pdf there,
> and produce those converted images via Makefile.;
Placing reST files together with the *autogenerated* (intermediate)
content from
* image conversions,
* reST content build from MAINTAINERS,
* reST content build for ABI
* etc.
has the nice side effect, that we can get rid of all theses BUILDDIR
quirks in the Makefile.sphinx
Additional, we can write Makefile targets to build the above listed
intermediate content relative to the $PWD, which is what Linux's
Makefiles usual do (instead of quirking with a BUILDDIR).
E.g. with, we can also get rid of the 'kernel-include' directive
and replace it, with Sphinx's common 'literaliclude' and we do not
need any extensions to include intermediate PDFs or whatever
intermediate content we might want to generate.
IMO placing 'sourcedir' to O= is more sane since this marries the
Linux Makefile concept (relative to $PWD) with the sphinx concept
(in or below 'sourcedir').
-- Markus --
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Markus Heiser @ 2016-11-09 9:22 UTC (permalink / raw)
To: Josh Triplett
Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel, linux-media,
ksummit-discuss, linux-doc
In-Reply-To: <20161107170133.4jdeuqydthbbchaq@x>
Am 07.11.2016 um 18:01 schrieb Josh Triplett <josh@joshtriplett.org>:
> On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote:
>> 2) add an Sphinx extension that would internally call ImageMagick and/or
>> inkscape to convert the bitmap;
>
> This seems sensible; Sphinx should directly handle the source format we
> want to use for images/diagrams.
>
>> 3) if possible, add an extension to trick Sphinx for it to consider the
>> output dir as a source dir too.
>
> Or to provide an additional source path and point that at the output
> directory.
The sphinx-build command excepts only one 'sourcedir' argument. All
reST files in this folder (and below) are parsed.
Most (all?) directives which include content like images or literalinclude
except only relative pathnames. Where *relative* means, relative to the
reST file where the directive is used. For security reasons relative
pathnames outside 'sourcepath' are not excepted.
So I vote for :
> 1) copy (or symlink) all rst files to Documentation/output (or to the
> build dir specified via O= directive) and generate the *.pdf there,
> and produce those converted images via Makefile.;
Placing reST files together with the *autogenerated* (intermediate)
content from
* image conversions,
* reST content build from MAINTAINERS,
* reST content build for ABI
* etc.
has the nice side effect, that we can get rid of all theses BUILDDIR
quirks in the Makefile.sphinx
Additional, we can write Makefile targets to build the above listed
intermediate content relative to the $PWD, which is what Linux's
Makefiles usual do (instead of quirking with a BUILDDIR).
E.g. with, we can also get rid of the 'kernel-include' directive
and replace it, with Sphinx's common 'literaliclude' and we do not
need any extensions to include intermediate PDFs or whatever
intermediate content we might want to generate.
IMO placing 'sourcedir' to O= is more sane since this marries the
Linux Makefile concept (relative to $PWD) with the sphinx concept
(in or below 'sourcedir').
-- Markus --
^ permalink raw reply
* Re: [PATCH 2/5] wic: use partition size when creating empty partition files
From: Ed Bartosh @ 2016-11-09 9:23 UTC (permalink / raw)
To: Maciej Borzecki; +Cc: Maciej Borzecki, openembedded-core
In-Reply-To: <927e5e94d6d20caf9b59e8e57895742f9ebebff8.1478619682.git.maciej.borzecki@rndity.com>
On Tue, Nov 08, 2016 at 04:56:08PM +0100, Maciej Borzecki wrote:
> It seems that prepare_empty_partition_ext() and
> prepare_empty_partition_btrfs() got broken in commit
> c8669749e37fe865c197c98d5671d9de176ff4dd, thus one could observe the
> following backtrace:
>
> Backtrace:
> File "<snip>/poky/scripts/lib/wic/plugins/imager/direct_plugin.py", line 93, in do_create
> creator.create()
> File "<snip>/poky/scripts/lib/wic/imager/baseimager.py", line 159, in create
> self._create()
> File "<snip>/poky/scripts/lib/wic/imager/direct.py", line 290, in _create
> self.bootimg_dir, self.kernel_dir, self.native_sysroot)
> File "<snip>/poky/scripts/lib/wic/partition.py", line 146, in prepare
> method(rootfs, oe_builddir, native_sysroot)
> File "<snip>/poky/scripts/lib/wic/partition.py", line 325, in prepare_empty_partition_ext
> os.ftruncate(sparse.fileno(), rootfs_size * 1024)
> NameError: name 'rootfs_size' is not defined
>
> Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
> ---
> scripts/lib/wic/partition.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> index 4b8d769437120adadb5dba2f3919d4eb96141292..8adc698240c8e3bd9f4118663a5d7a167e0bb4a4 100644
> --- a/scripts/lib/wic/partition.py
> +++ b/scripts/lib/wic/partition.py
> @@ -308,7 +308,7 @@ class Partition():
> Prepare an empty ext2/3/4 partition.
> """
> with open(rootfs, 'w') as sparse:
> - os.ftruncate(sparse.fileno(), rootfs_size * 1024)
> + os.ftruncate(sparse.fileno(), self.size * 1024)
>
> extra_imagecmd = "-i 8192"
>
> @@ -326,7 +326,7 @@ class Partition():
> Prepare an empty btrfs partition.
> """
> with open(rootfs, 'w') as sparse:
> - os.ftruncate(sparse.fileno(), rootfs_size * 1024)
> + os.ftruncate(sparse.fileno(), self.size * 1024)
>
> label_str = ""
> if self.label:
Thank you for the fix. Sorry for breaking this. I thought I
double-checked and all tests were passing :(
--
Regards,
Ed
^ permalink raw reply
* Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions
From: Duy Nguyen @ 2016-11-09 9:24 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <CACsJy8DjXrOgB-_-t47uSdCQFg9s_o+Oj9NBmAhDFZ3aYvjBgg@mail.gmail.com>
On Mon, Nov 7, 2016 at 5:08 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Oct 30, 2016 at 5:06 AM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>>> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
>>> <christian.couder@gmail.com> wrote:
>>>> +void remove_split_index(struct index_state *istate)
>>>> +{
>>>> + if (istate->split_index) {
>>>> + /*
>>>> + * can't discard_split_index(&the_index); because that
>>>> + * will destroy split_index->base->cache[], which may
>>>> + * be shared with the_index.cache[]. So yeah we're
>>>> + * leaking a bit here.
>>>
>>> In the context of update-index, this is a one-time thing and leaking
>>> is tolerable. But because it becomes a library function now, this leak
>>> can become more serious, I think.
>>>
>>> The only other (indirect) caller is read_index_from() so probably not
>>> bad most of the time (we read at the beginning of a command only).
>>> sequencer.c may discard and re-read the index many times though,
>>> leaking could be visible there.
>>
>> So is it enough to check if split_index->base->cache[] is shared with
>> the_index.cache[] and then decide if discard_split_index(&the_index)
>> should be called?
>
> It's likely shared though. We could un-share cache[] by duplicating
> index entries in the_index.cache[] if they point back to
> split_index->base
I have a patch for this. So don't have to do anything else in this
area. I'll probably just pile my patch on top of your series, or post
it once the series graduates to master.
--
Duy
^ permalink raw reply
* [Buildroot] [PATCH 1/2] python: fix double format detection
From: Jérôme Pouiller @ 2016-11-09 9:25 UTC (permalink / raw)
To: buildroot
Python is not able to detect if compiler double representation is
compliant with IEE754:
checking whether C doubles are little-endian IEEE 754 binary64... no
checking whether C doubles are big-endian IEEE 754 binary64... no
checking whether C doubles are ARM mixed-endian IEEE 754 binary64... no
Accordingly 'legacy' mode isused. It is possible to check this at runtime by
check if 'sys.float_repr_style' contains 'short' or 'legacy'. Calculus
correctness is not garanteed with 'legacy'.
Problem is better described here:
http://stackoverflow.com/questions/29920294/what-causes-pythons-float-repr-style-to-use-legacy
https://bugs.python.org/issue7117
However, all gcc architecture use a representation compliant with IEE754. So,
we can enable it unconditionnaly.
Signed-off-by: J?r?me Pouiller <jezz@sysmic.org>
---
package/python/python.mk | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/package/python/python.mk b/package/python/python.mk
index cc65376..0191d59 100644
--- a/package/python/python.mk
+++ b/package/python/python.mk
@@ -140,6 +140,13 @@ PYTHON_CONF_ENV += \
ac_cv_prog_HAS_HG=/bin/false \
ac_cv_prog_SVNVERSION=/bin/false
+# GCC is always complient with IEEE754
+ifeq ($(call qstrip,$(BR2_ENDIAN)),LITTLE)
+PYTHON_CONF_ENV += ac_cv_little_endian_double=yes
+else
+PYTHON_CONF_ENV += ac_cv_big_endian_double=yes
+endif
+
PYTHON_CONF_OPTS += \
--without-cxx-main \
--without-doc-strings \
--
2.9.3
^ permalink raw reply related
* [Buildroot] [PATCH 2/2] python3: fix double format detection
From: Jérôme Pouiller @ 2016-11-09 9:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109092508.4503-1-jezz@sysmic.org>
Python is not able to detect if compiler double representation is
compliant with IEE754:
checking whether C doubles are little-endian IEEE 754 binary64... no
checking whether C doubles are big-endian IEEE 754 binary64... no
checking whether C doubles are ARM mixed-endian IEEE 754 binary64... no
Accordingly 'legacy' mode isused. It is possible to check this at runtime by
check if 'sys.float_repr_style' contains 'short' or 'legacy'. Calculus
correctness is not garanteed with 'legacy'.
Problem is better described here:
http://stackoverflow.com/questions/29920294/what-causes-pythons-float-repr-style-to-use-legacy
https://bugs.python.org/issue7117
However, all gcc architecture use a representation compliant with IEE754. So,
we can enable it unconditionnaly.
Signed-off-by: J?r?me Pouiller <jezz@sysmic.org>
---
package/python3/python3.mk | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/package/python3/python3.mk b/package/python3/python3.mk
index b3f31c0..cdbe6f0 100644
--- a/package/python3/python3.mk
+++ b/package/python3/python3.mk
@@ -126,6 +126,13 @@ PYTHON3_CONF_ENV += \
ac_cv_working_tzset=yes \
ac_cv_prog_HAS_HG=/bin/false
+# GCC is always compliant with IEEE754
+ifeq ($(call qstrip,$(BR2_ENDIAN)),LITTLE)
+PYTHON3_CONF_ENV += ac_cv_little_endian_double=yes
+else
+PYTHON3_CONF_ENV += ac_cv_big_endian_double=yes
+endif
+
# uClibc is known to have a broken wcsftime() implementation, so tell
# Python 3 to fall back to strftime() instead.
ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 8/9] xfs: fuzz every field of every structure
From: Darrick J. Wong @ 2016-11-09 9:25 UTC (permalink / raw)
To: Eryu Guan; +Cc: david, linux-xfs, fstests
In-Reply-To: <20161109091344.GX27776@eguan.usersys.redhat.com>
On Wed, Nov 09, 2016 at 05:13:44PM +0800, Eryu Guan wrote:
> On Wed, Nov 09, 2016 at 12:52:36AM -0800, Darrick J. Wong wrote:
> > On Wed, Nov 09, 2016 at 04:09:24PM +0800, Eryu Guan wrote:
> > > On Fri, Nov 04, 2016 at 05:18:00PM -0700, Darrick J. Wong wrote:
> > > > Previously, our XFS fuzzing efforts were limited to using the xfs_db
> > > > blocktrash command to scribble garbage all over a block. This is
> > > > pretty easy to discover; it would be far more interesting if we could
> > > > fuzz individual fields looking for unhandled corner cases. Since we
> > > > now have an online scrub tool, use it to check for our targeted
> > > > corruptions prior to the usual steps of writing to the FS, taking it
> > > > offline, repairing, and re-checking.
> > > >
> > > > These tests use the new xfs_db 'fuzz' command to test corner case
> > > > handling of every field. The 'print' command tells us which fields
> > > > are available, and the fuzz command can write zeroes or ones to the
> > > > field; set the high, middle, or low bit; add or subtract numbers; or
> > > > randomize the field. We loop through all fields and all fuzz verbs to
> > > > see if we can trip up the kernel.
> > > >
> > > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > >
> > > The first test gave me a kernel crash :) xfs/1300 crashed your kernel
> > > djwong-devel branch. I appended the console log at the end of this mail
> > > if you have interest to see it.
> > >
> > > And another xfs/1300 run gave me this failure message:
> > >
> > > +/mnt/testarea/scratch: Kernel lacks GETFSMAP; scrub will be less efficient. (xfs.c line 661)
> > > +/mnt/testarea/scratch: Kernel cannot help scrub metadata; scrub will be incomplete. (xfs.c line 661)
> > > +/mnt/testarea/scratch: Kernel cannot help scrub inodes; scrub will be incomplete. (xfs.c line 661)
> > > +/mnt/testarea/scratch: Kernel cannot help scrub extent map; scrub will be less efficient. (xfs.c line 661)
> > >
> > > Is this known issue or something should be filtered out in the test?
> >
> > That's strange, the djwong-devel branch should have getfsmap & scrub in it...
> >
> > ...are you running the djwong-devel kernel and xfsprogs code? The scrub
> > ioctl structure has shifted some over the past few months, though GETFSMAP
> > hasn't changed in ages.
> >
> > Wait, "another xfs/1300 run" ... so after the first crash, did you go
> > back to a vanilla kernel without all my crazypatches? :)
>
> Ahh, you're right! It booted into 4.9-rc4 vanilla kernel, sorry about
> that.. But xfs/1300 crashed djwong-devel for the second time in my
> second try, seems the crash is reliable reproduced, with reflink
> enabled.
I think if you change the XFS_SCRUB_OP_ERROR_GOTO at line 2237 of
xfs_scrub_get_inode() to "if (error) goto out_err;" that ought to clear it up.
> > > And ext4/1300 generated large .out.bad file (51M), containing something
> > > like:
> > >
> > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101381632/2469888/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > >
> > > Seems like scrub found something wrong (real problems) and became very
> > > noisy?
> >
> > Hmm that's even stranger. I'll try to reproduce tomorrow.
>
> So this ext4 noise came from the vanilla kernel too, retested with
> djwong-devel kernel & userspace ext4/1300 passed without problems. Sorry
> for my noise..
But that's even more weird; there haven't been any changes to ext4 that
would explain why this breaks on a vanilla 4.9-rc4 kernel...
--D
>
> Thanks,
> Eryu
^ permalink raw reply
* Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability
From: Thomas Gleixner @ 2016-11-09 9:23 UTC (permalink / raw)
To: Lu Baolu
Cc: Greg Kroah-Hartman, Mathias Nyman, Ingo Molnar, linux-usb, x86,
LKML, Peter Zijlstra
In-Reply-To: <1477976354-13291-2-git-send-email-baolu.lu@linux.intel.com>
On Tue, 1 Nov 2016, Lu Baolu wrote:
> +static int __init xdbc_init(void)
> +{
...
> + base = ioremap_nocache(xdbc.xhci_start, xdbc.xhci_length);
> + if (!base) {
> + xdbc_trace("failed to remap the io address\n");
> + ret = -ENOMEM;
> + goto free_and_quit;
> + }
> +
> + early_iounmap(xdbc.xhci_base, xdbc.xhci_length);
> + xdbc_trace("early mapped IO address released\n");
> +
> + xdbc.xhci_base = base;
> + offset = xhci_find_next_ext_cap(xdbc.xhci_base, 0, XHCI_EXT_CAPS_DEBUG);
> + xdbc.xdbc_reg = (struct xdbc_regs __iomem *)(xdbc.xhci_base + offset);
This is broken. What prevents that
- a printk is in progress on another cpu?
- a printk happens between the unmap and storing the new base ?
Nothing AFAICT. So this needs to be done in a safe way. And just making it
oldbase = xdbc.xhci_base;
base = ioremap(....);
xdbc.xhci_base = base;
early_iounmap(oldbase);
does not work either because the compiler can rightfully cache
xdbc.xhci_base in the write related functions. The same issue with
xdbc.xdbc_reg.
Thanks,
tglx
^ permalink raw reply
* Re: WTF: patch "[PATCH] rtlwifi: Fix regression caused by commit d86e64768859" was seriously submitted to be applied to the 4.8-stable tree?
From: Larry Finger @ 2016-11-09 9:23 UTC (permalink / raw)
To: gregkh, Julia.Lawall, johannes, kvalo, stable
In-Reply-To: <1478622357191168@kroah.com>
On 11/08/2016 10:25 AM, gregkh@linuxfoundation.org wrote:
> The patch below was submitted to be applied to the 4.8-stable tree.
>
> I fail to see how this patch meets the stable kernel rules as found at
> Documentation/stable_kernel_rules.txt.
>
> I could be totally wrong, and if so, please respond to
> <stable@vger.kernel.org> and let me know why this patch should be
> applied. Otherwise, it is now dropped from my patch queues, never to be
> seen again.
Greg,
Dropping this patch is the correct action. I got confused over the material in
net-next as contrasted with mainline, thus I used the stable indication in error.
Sorry for any confusion,
Larry
^ permalink raw reply
* [PATCH] staging: sm750fb: prefix global identifiers
From: Arnd Bergmann @ 2016-11-09 9:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Sudip Mukherjee, Teddy Wang, Mike Rapoport,
Elise Lennion, linux-fbdev, devel, linux-kernel
Renaming some symbols inside this driver caused a conflict with
an existing function, which in turn results in a link error:
drivers/staging/sm750fb/sm750fb.o: In function `enable_dma':
ddk750_hwi2c.c:(.text.enable_dma+0x0): multiple definition of `enable_dma'
This adds a sm750_ prefix to each global symbol in the sm750fb
driver that does not already have one. I manually looked for the
symbols and then converted the driver using
for i in calc_pll_value format_pll_reg set_power_mode set_current_gate \
enable_2d_engine enable_dma enable_gpio enable_i2c hw_set2dformat \
hw_de_init hw_fillrect hw_copyarea hw_imageblit hw_cursor_enable \
hw_cursor_disable hw_cursor_setSize hw_cursor_setPos \
hw_cursor_setColor hw_cursor_setData hw_cursor_setData2 ;
do
sed -i "s:\<$i\>:sm750_$i:" drivers/staging/sm750fb/*.[ch]
done
Fixes: 03140dabf584 ("staging: sm750fb: Replace functions CamelCase naming with underscores.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/staging/sm750fb/ddk750_chip.c | 24 ++++++++++++------------
drivers/staging/sm750fb/ddk750_chip.h | 4 ++--
drivers/staging/sm750fb/ddk750_hwi2c.c | 4 ++--
drivers/staging/sm750fb/ddk750_mode.c | 6 +++---
drivers/staging/sm750fb/ddk750_power.c | 20 ++++++++++----------
drivers/staging/sm750fb/ddk750_power.h | 12 ++++++------
drivers/staging/sm750fb/ddk750_swi2c.c | 2 +-
drivers/staging/sm750fb/sm750.c | 22 +++++++++++-----------
drivers/staging/sm750fb/sm750_accel.c | 10 +++++-----
drivers/staging/sm750fb/sm750_accel.h | 10 +++++-----
drivers/staging/sm750fb/sm750_cursor.c | 14 +++++++-------
drivers/staging/sm750fb/sm750_cursor.h | 14 +++++++-------
drivers/staging/sm750fb/sm750_hw.c | 4 ++--
13 files changed, 73 insertions(+), 73 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
index 14b5112dfb03..94f59f446322 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -68,16 +68,16 @@ static void set_chip_clock(unsigned int frequency)
pll.clockType = MXCLK_PLL;
/*
- * Call calc_pll_value() to fill the other fields of the PLL
+ * Call sm750_calc_pll_value() to fill the other fields of the PLL
* structure. Sometimes, the chip cannot set up the exact
* clock required by the User.
- * Return value of calc_pll_value gives the actual possible
+ * Return value of sm750_calc_pll_value gives the actual possible
* clock.
*/
- ulActualMxClk = calc_pll_value(frequency, &pll);
+ ulActualMxClk = sm750_calc_pll_value(frequency, &pll);
/* Master Clock Control: MXCLK_PLL */
- POKE32(MXCLK_PLL_CTRL, format_pll_reg(&pll));
+ POKE32(MXCLK_PLL_CTRL, sm750_format_pll_reg(&pll));
}
}
@@ -121,7 +121,7 @@ static void set_memory_clock(unsigned int frequency)
break;
}
- set_current_gate(reg);
+ sm750_set_current_gate(reg);
}
}
@@ -173,7 +173,7 @@ static void set_master_clock(unsigned int frequency)
break;
}
- set_current_gate(reg);
+ sm750_set_current_gate(reg);
}
}
@@ -215,12 +215,12 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
if (pInitParam->powerMode != 0)
pInitParam->powerMode = 0;
- set_power_mode(pInitParam->powerMode);
+ sm750_set_power_mode(pInitParam->powerMode);
/* Enable display power gate & LOCALMEM power gate*/
reg = PEEK32(CURRENT_GATE);
reg |= (CURRENT_GATE_DISPLAY | CURRENT_GATE_LOCALMEM);
- set_current_gate(reg);
+ sm750_set_current_gate(reg);
if (sm750_get_chip_type() != SM750LE) {
/* set panel pll and graphic mode via mmio_88 */
@@ -261,7 +261,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
}
if (pInitParam->setAllEngOff = 1) {
- enable_2d_engine(0);
+ sm750_enable_2d_engine(0);
/* Disable Overlay, if a former application left it on */
reg = PEEK32(VIDEO_DISPLAY_CTRL);
@@ -284,7 +284,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
POKE32(DMA_ABORT_INTERRUPT, reg);
/* Disable DMA Power, if a former application left it on */
- enable_dma(0);
+ sm750_enable_dma(0);
}
/* We can add more initialization as needed. */
@@ -309,7 +309,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
* M = {1,...,255}
* N = {2,...,15}
*/
-unsigned int calc_pll_value(unsigned int request_orig, struct pll_value *pll)
+unsigned int sm750_calc_pll_value(unsigned int request_orig, struct pll_value *pll)
{
/*
* as sm750 register definition,
@@ -381,7 +381,7 @@ unsigned int calc_pll_value(unsigned int request_orig, struct pll_value *pll)
return ret;
}
-unsigned int format_pll_reg(struct pll_value *pPLL)
+unsigned int sm750_format_pll_reg(struct pll_value *pPLL)
{
#ifndef VALIDATION_CHIP
unsigned int POD = pPLL->POD;
diff --git a/drivers/staging/sm750fb/ddk750_chip.h b/drivers/staging/sm750fb/ddk750_chip.h
index 5eee29dfc4b3..e97e8592d973 100644
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -88,8 +88,8 @@ struct initchip_param {
logical_chip_type_t sm750_get_chip_type(void);
void sm750_set_chip_type(unsigned short devId, char revId);
-unsigned int calc_pll_value(unsigned int request, struct pll_value *pll);
-unsigned int format_pll_reg(struct pll_value *pPLL);
+unsigned int sm750_calc_pll_value(unsigned int request, struct pll_value *pll);
+unsigned int sm750_format_pll_reg(struct pll_value *pPLL);
unsigned int ddk750_get_vm_size(void);
int ddk750_init_hw(struct initchip_param *);
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 10439e061ae8..05d4a73aa1d4 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -24,7 +24,7 @@ unsigned char bus_speed_mode
* Enable Hardware I2C power.
* TODO: Check if we need to enable GPIO power?
*/
- enable_i2c(1);
+ sm750_enable_i2c(1);
/* Enable the I2C Controller and set the bus speed mode */
value = PEEK32(I2C_CTRL) & ~(I2C_CTRL_MODE | I2C_CTRL_EN);
@@ -45,7 +45,7 @@ void sm750_hw_i2c_close(void)
POKE32(I2C_CTRL, value);
/* Disable I2C Power */
- enable_i2c(0);
+ sm750_enable_i2c(0);
/* Set GPIO 30 & 31 back as GPIO pins */
value = PEEK32(GPIO_MUX);
diff --git a/drivers/staging/sm750fb/ddk750_mode.c b/drivers/staging/sm750fb/ddk750_mode.c
index 47d224e542c3..4a4b1de97a87 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -83,7 +83,7 @@ static int programModeRegisters(mode_parameter_t *pModeParam,
if (pll->clockType = SECONDARY_PLL) {
/* programe secondary pixel clock */
- POKE32(CRT_PLL_CTRL, format_pll_reg(pll));
+ POKE32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
POKE32(CRT_HORIZONTAL_TOTAL,
(((pModeParam->horizontal_total - 1) <<
CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
@@ -133,7 +133,7 @@ static int programModeRegisters(mode_parameter_t *pModeParam,
} else if (pll->clockType = PRIMARY_PLL) {
unsigned int reserved;
- POKE32(PANEL_PLL_CTRL, format_pll_reg(pll));
+ POKE32(PANEL_PLL_CTRL, sm750_format_pll_reg(pll));
reg = ((pModeParam->horizontal_total - 1) <<
PANEL_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
@@ -210,7 +210,7 @@ int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock)
pll.inputFreq = DEFAULT_INPUT_CLOCK;
pll.clockType = clock;
- uiActualPixelClk = calc_pll_value(parm->pixel_clock, &pll);
+ uiActualPixelClk = sm750_calc_pll_value(parm->pixel_clock, &pll);
if (sm750_get_chip_type() = SM750LE) {
/* set graphic mode via IO method */
outb_p(0x88, 0x3d4);
diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
index 6f4374057405..6167e30e8e01 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -29,7 +29,7 @@ static unsigned int get_power_mode(void)
* SM50x can operate in one of three modes: 0, 1 or Sleep.
* On hardware reset, power mode 0 is default.
*/
-void set_power_mode(unsigned int mode)
+void sm750_set_power_mode(unsigned int mode)
{
unsigned int ctrl = 0;
@@ -72,7 +72,7 @@ void set_power_mode(unsigned int mode)
POKE32(POWER_MODE_CTRL, ctrl);
}
-void set_current_gate(unsigned int gate)
+void sm750_set_current_gate(unsigned int gate)
{
if (get_power_mode() = POWER_MODE_CTRL_MODE_MODE1)
POKE32(MODE1_GATE, gate);
@@ -85,7 +85,7 @@ void set_current_gate(unsigned int gate)
/*
* This function enable/disable the 2D engine.
*/
-void enable_2d_engine(unsigned int enable)
+void sm750_enable_2d_engine(unsigned int enable)
{
u32 gate;
@@ -95,10 +95,10 @@ void enable_2d_engine(unsigned int enable)
else
gate &= ~(CURRENT_GATE_DE | CURRENT_GATE_CSC);
- set_current_gate(gate);
+ sm750_set_current_gate(gate);
}
-void enable_dma(unsigned int enable)
+void sm750_enable_dma(unsigned int enable)
{
u32 gate;
@@ -109,13 +109,13 @@ void enable_dma(unsigned int enable)
else
gate &= ~CURRENT_GATE_DMA;
- set_current_gate(gate);
+ sm750_set_current_gate(gate);
}
/*
* This function enable/disable the GPIO Engine
*/
-void enable_gpio(unsigned int enable)
+void sm750_enable_gpio(unsigned int enable)
{
u32 gate;
@@ -126,13 +126,13 @@ void enable_gpio(unsigned int enable)
else
gate &= ~CURRENT_GATE_GPIO;
- set_current_gate(gate);
+ sm750_set_current_gate(gate);
}
/*
* This function enable/disable the I2C Engine
*/
-void enable_i2c(unsigned int enable)
+void sm750_enable_i2c(unsigned int enable)
{
u32 gate;
@@ -143,7 +143,7 @@ void enable_i2c(unsigned int enable)
else
gate &= ~CURRENT_GATE_I2C;
- set_current_gate(gate);
+ sm750_set_current_gate(gate);
}
diff --git a/drivers/staging/sm750fb/ddk750_power.h b/drivers/staging/sm750fb/ddk750_power.h
index ea56026d41b2..eb088b0d805f 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -15,28 +15,28 @@ DPMS_t;
}
void ddk750_set_dpms(DPMS_t);
-void set_power_mode(unsigned int powerMode);
-void set_current_gate(unsigned int gate);
+void sm750_set_power_mode(unsigned int powerMode);
+void sm750_set_current_gate(unsigned int gate);
/*
* This function enable/disable the 2D engine.
*/
-void enable_2d_engine(unsigned int enable);
+void sm750_enable_2d_engine(unsigned int enable);
/*
* This function enable/disable the DMA Engine
*/
-void enable_dma(unsigned int enable);
+void sm750_enable_dma(unsigned int enable);
/*
* This function enable/disable the GPIO Engine
*/
-void enable_gpio(unsigned int enable);
+void sm750_enable_gpio(unsigned int enable);
/*
* This function enable/disable the I2C Engine
*/
-void enable_i2c(unsigned int enable);
+void sm750_enable_i2c(unsigned int enable);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
index e2e3ca64d483..b8a4e44359af 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -428,7 +428,7 @@ long sm750_sw_i2c_init(
PEEK32(sw_i2c_data_gpio_mux_reg) & ~(1 << sw_i2c_data_gpio));
/* Enable GPIO power */
- enable_gpio(1);
+ sm750_enable_gpio(1);
/* Clear the i2c lines. */
for (i = 0; i < 9; i++)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 5c153d68212a..2d22c51cb33b 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -118,14 +118,14 @@ static int lynxfb_ops_cursor(struct fb_info *info, struct fb_cursor *fbcursor)
return -ENXIO;
}
- hw_cursor_disable(cursor);
+ sm750_hw_cursor_disable(cursor);
if (fbcursor->set & FB_CUR_SETSIZE)
- hw_cursor_setSize(cursor,
+ sm750_hw_cursor_setSize(cursor,
fbcursor->image.width,
fbcursor->image.height);
if (fbcursor->set & FB_CUR_SETPOS)
- hw_cursor_setPos(cursor,
+ sm750_hw_cursor_setPos(cursor,
fbcursor->image.dx - info->var.xoffset,
fbcursor->image.dy - info->var.yoffset);
@@ -141,18 +141,18 @@ static int lynxfb_ops_cursor(struct fb_info *info, struct fb_cursor *fbcursor)
((info->cmap.green[fbcursor->image.bg_color] & 0xfc00) >> 5) |
((info->cmap.blue[fbcursor->image.bg_color] & 0xf800) >> 11);
- hw_cursor_setColor(cursor, fg, bg);
+ sm750_hw_cursor_setColor(cursor, fg, bg);
}
if (fbcursor->set & (FB_CUR_SETSHAPE | FB_CUR_SETIMAGE)) {
- hw_cursor_setData(cursor,
+ sm750_hw_cursor_setData(cursor,
fbcursor->rop,
fbcursor->image.data,
fbcursor->mask);
}
if (fbcursor->enable)
- hw_cursor_enable(cursor);
+ sm750_hw_cursor_enable(cursor);
return 0;
}
@@ -788,7 +788,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
if (!g_hwcursor) {
lynxfb_ops.fb_cursor = NULL;
- hw_cursor_disable(&crtc->cursor);
+ sm750_hw_cursor_disable(&crtc->cursor);
}
/* set info->fbops, must be set before fb_find_mode */
@@ -1083,10 +1083,10 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
* if some chip need specific function,
* please hook it in smXXX_set_drv routine
*/
- sm750_dev->accel.de_init = hw_de_init;
- sm750_dev->accel.de_fillrect = hw_fillrect;
- sm750_dev->accel.de_copyarea = hw_copyarea;
- sm750_dev->accel.de_imageblit = hw_imageblit;
+ sm750_dev->accel.de_init = sm750_hw_de_init;
+ sm750_dev->accel.de_fillrect = sm750_hw_fillrect;
+ sm750_dev->accel.de_copyarea = sm750_hw_copyarea;
+ sm750_dev->accel.de_imageblit = sm750_hw_imageblit;
}
/* call chip specific setup routine */
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 2e9c94142274..6fd18d24f5b2 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -32,7 +32,7 @@ static inline void write_dpPort(struct lynx_accel *accel, u32 data)
writel(data, accel->dpPortBase);
}
-void hw_de_init(struct lynx_accel *accel)
+void sm750_hw_de_init(struct lynx_accel *accel)
{
/* setup 2d engine registers */
u32 reg, clr;
@@ -71,7 +71,7 @@ void hw_de_init(struct lynx_accel *accel)
* every time you use 2d function
*/
-void hw_set2dformat(struct lynx_accel *accel, int fmt)
+void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
{
u32 reg;
@@ -83,7 +83,7 @@ void hw_set2dformat(struct lynx_accel *accel, int fmt)
write_dpr(accel, DE_STRETCH_FORMAT, reg);
}
-int hw_fillrect(struct lynx_accel *accel,
+int sm750_hw_fillrect(struct lynx_accel *accel,
u32 base, u32 pitch, u32 Bpp,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop)
@@ -128,7 +128,7 @@ int hw_fillrect(struct lynx_accel *accel,
return 0;
}
-int hw_copyarea(
+int sm750_hw_copyarea(
struct lynx_accel *accel,
unsigned int sBase, /* Address of source: offset in frame buffer */
unsigned int sPitch, /* Pitch value of source surface in BYTE */
@@ -293,7 +293,7 @@ static unsigned int deGetTransparency(struct lynx_accel *accel)
return de_ctrl;
}
-int hw_imageblit(struct lynx_accel *accel,
+int sm750_hw_imageblit(struct lynx_accel *accel,
const char *pSrcbuf, /* pointer to start of source buffer in system memory */
u32 srcDelta, /* Pitch value (in bytes) of the source buffer, +ive means top down and -ive mean button up */
u32 startBit, /* Mono data can start at any bit in a byte, this value should be 0 to 7 */
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index d59d005e0add..4b0ff8feb9a0 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -184,16 +184,16 @@
#define BOTTOM_TO_TOP 1
#define RIGHT_TO_LEFT 1
-void hw_set2dformat(struct lynx_accel *accel, int fmt);
+void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt);
-void hw_de_init(struct lynx_accel *accel);
+void sm750_hw_de_init(struct lynx_accel *accel);
-int hw_fillrect(struct lynx_accel *accel,
+int sm750_hw_fillrect(struct lynx_accel *accel,
u32 base, u32 pitch, u32 Bpp,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop);
-int hw_copyarea(
+int sm750_hw_copyarea(
struct lynx_accel *accel,
unsigned int sBase, /* Address of source: offset in frame buffer */
unsigned int sPitch, /* Pitch value of source surface in BYTE */
@@ -208,7 +208,7 @@ unsigned int width,
unsigned int height, /* width and height of rectangle in pixel value */
unsigned int rop2);
-int hw_imageblit(struct lynx_accel *accel,
+int sm750_hw_imageblit(struct lynx_accel *accel,
const char *pSrcbuf, /* pointer to start of source buffer in system memory */
u32 srcDelta, /* Pitch value (in bytes) of the source buffer, +ive means top down and -ive mean button up */
u32 startBit, /* Mono data can start at any bit in a byte, this value should be 0 to 7 */
diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
index d622d65b6cee..2a13353fc492 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -47,25 +47,25 @@ writel((data), cursor->mmio + (addr))
/* hw_cursor_xxx works for voyager,718 and 750 */
-void hw_cursor_enable(struct lynx_cursor *cursor)
+void sm750_hw_cursor_enable(struct lynx_cursor *cursor)
{
u32 reg;
reg = (cursor->offset & HWC_ADDRESS_ADDRESS_MASK) | HWC_ADDRESS_ENABLE;
POKE32(HWC_ADDRESS, reg);
}
-void hw_cursor_disable(struct lynx_cursor *cursor)
+void sm750_hw_cursor_disable(struct lynx_cursor *cursor)
{
POKE32(HWC_ADDRESS, 0);
}
-void hw_cursor_setSize(struct lynx_cursor *cursor,
+void sm750_hw_cursor_setSize(struct lynx_cursor *cursor,
int w, int h)
{
cursor->w = w;
cursor->h = h;
}
-void hw_cursor_setPos(struct lynx_cursor *cursor,
+void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
int x, int y)
{
u32 reg;
@@ -74,7 +74,7 @@ void hw_cursor_setPos(struct lynx_cursor *cursor,
(x & HWC_LOCATION_X_MASK));
POKE32(HWC_LOCATION, reg);
}
-void hw_cursor_setColor(struct lynx_cursor *cursor,
+void sm750_hw_cursor_setColor(struct lynx_cursor *cursor,
u32 fg, u32 bg)
{
u32 reg = (fg << HWC_COLOR_12_2_RGB565_SHIFT) &
@@ -84,7 +84,7 @@ void hw_cursor_setColor(struct lynx_cursor *cursor,
POKE32(HWC_COLOR_3, 0xffe0);
}
-void hw_cursor_setData(struct lynx_cursor *cursor,
+void sm750_hw_cursor_setData(struct lynx_cursor *cursor,
u16 rop, const u8 *pcol, const u8 *pmsk)
{
int i, j, count, pitch, offset;
@@ -138,7 +138,7 @@ void hw_cursor_setData(struct lynx_cursor *cursor,
}
-void hw_cursor_setData2(struct lynx_cursor *cursor,
+void sm750_hw_cursor_setData2(struct lynx_cursor *cursor,
u16 rop, const u8 *pcol, const u8 *pmsk)
{
int i, j, count, pitch, offset;
diff --git a/drivers/staging/sm750fb/sm750_cursor.h b/drivers/staging/sm750fb/sm750_cursor.h
index 6c4fc9b73489..c7b86ae235b4 100644
--- a/drivers/staging/sm750fb/sm750_cursor.h
+++ b/drivers/staging/sm750fb/sm750_cursor.h
@@ -2,16 +2,16 @@
#define LYNX_CURSOR_H__
/* hw_cursor_xxx works for voyager,718 and 750 */
-void hw_cursor_enable(struct lynx_cursor *cursor);
-void hw_cursor_disable(struct lynx_cursor *cursor);
-void hw_cursor_setSize(struct lynx_cursor *cursor,
+void sm750_hw_cursor_enable(struct lynx_cursor *cursor);
+void sm750_hw_cursor_disable(struct lynx_cursor *cursor);
+void sm750_hw_cursor_setSize(struct lynx_cursor *cursor,
int w, int h);
-void hw_cursor_setPos(struct lynx_cursor *cursor,
+void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
int x, int y);
-void hw_cursor_setColor(struct lynx_cursor *cursor,
+void sm750_hw_cursor_setColor(struct lynx_cursor *cursor,
u32 fg, u32 bg);
-void hw_cursor_setData(struct lynx_cursor *cursor,
+void sm750_hw_cursor_setData(struct lynx_cursor *cursor,
u16 rop, const u8 *data, const u8 *mask);
-void hw_cursor_setData2(struct lynx_cursor *cursor,
+void sm750_hw_cursor_setData2(struct lynx_cursor *cursor,
u16 rop, const u8 *data, const u8 *mask);
#endif
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 23b6b1cda529..b6af3b53076b 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -275,7 +275,7 @@ int hw_sm750_crtc_setMode(struct lynxfb_crtc *crtc,
fmt = 2;
break;
}
- hw_set2dformat(&sm750_dev->accel, fmt);
+ sm750_hw_set2dformat(&sm750_dev->accel, fmt);
}
/* set timing */
@@ -479,7 +479,7 @@ void hw_sm750_initAccel(struct sm750_dev *sm750_dev)
{
u32 reg;
- enable_2d_engine(1);
+ sm750_enable_2d_engine(1);
if (sm750_get_chip_type() = SM750LE) {
reg = PEEK32(DE_STATE1);
--
2.9.0
^ permalink raw reply related
* [PATCH] mm/hugetlb.c: mark alloc_gigantic_page stub inline
From: Arnd Bergmann @ 2016-11-09 9:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Huang Shijie, Steve Capper, Arnd Bergmann, Naoya Horiguchi,
Michal Hocko, Mike Kravetz, linux-mm, linux-kernel
A cleanup patch introduced a new stub helper function but
accidentally did not mark that 'inline' as all the other
stubs are here, and this causes a warning when it is
not used:
mm/hugetlb.c:1166:21: error: 'alloc_gigantic_page' defined but not used [-Werror=unused-function]
Fixes: akpm-current ("mm/hugetlb.c: rename some allocation functions")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 67faaca8c097..cb9e995affce 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1163,7 +1163,7 @@ static inline void destroy_compound_gigantic_page(struct page *page,
unsigned int order) { }
static inline int alloc_fresh_gigantic_page(struct hstate *h,
nodemask_t *nodes_allowed) { return 0; }
-static struct page *alloc_gigantic_page(int nid, unsigned int order)
+static inline struct page *alloc_gigantic_page(int nid, unsigned int order)
{
return NULL;
}
--
2.9.0
^ permalink raw reply related
* Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC
From: Brian Starkey @ 2016-11-09 9:27 UTC (permalink / raw)
To: Jaewon Kim; +Cc: linux-mm, linux-kernel
In-Reply-To: <1478682609-26477-1-git-send-email-jaewon31.kim@samsung.com>
Hi Jaewon,
On Wed, Nov 09, 2016 at 06:10:09PM +0900, Jaewon Kim wrote:
>Commit 6b03ae0d42bf (drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MA)
>added MEMREMAP_WC for DMA_MEMORY_MAP. If, however, CPU cache can be used on
>DMA_MEMORY_MAP, I think MEMREMAP_WC can be changed to MEMREMAP_WB. On my local
>ARM device, memset in dma_alloc_from_coherent sometimes takes much longer with
>MEMREMAP_WC compared to MEMREMAP_WB.
>
>Test results on AArch64 by allocating 4MB with putting trace_printk right
>before and after memset.
> MEMREMAP_WC : 11.0ms, 5.7ms, 4.2ms, 4.9ms, 5.4ms, 4.3ms, 3.5ms
> MEMREMAP_WB : 0.7ms, 0.6ms, 0.6ms, 0.6ms, 0.6ms, 0.5ms, 0.4 ms
>
This doesn't look like a good idea to me. The point of coherent memory
is to have it non-cached, however WB will make writes hit the cache.
Writing to the cache is of course faster than writing to RAM, but
that's not what we want to do here.
-Brian
>Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
>---
> drivers/base/dma-coherent.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
>index 640a7e6..0512a1d 100644
>--- a/drivers/base/dma-coherent.c
>+++ b/drivers/base/dma-coherent.c
>@@ -33,7 +33,7 @@ static bool dma_init_coherent_memory(
> goto out;
>
> if (flags & DMA_MEMORY_MAP)
>- mem_base = memremap(phys_addr, size, MEMREMAP_WC);
>+ mem_base = memremap(phys_addr, size, MEMREMAP_WB);
> else
> mem_base = ioremap(phys_addr, size);
> if (!mem_base)
>--
>1.9.1
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [Buildroot] [PATCH] htop: enable unicode if possible
From: Jérôme Pouiller @ 2016-11-09 9:27 UTC (permalink / raw)
To: buildroot
Signed-off-by: J?r?me Pouiller <jezz@sysmic.org>
---
package/htop/htop.mk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/htop/htop.mk b/package/htop/htop.mk
index 7409a78..e1a658b 100644
--- a/package/htop/htop.mk
+++ b/package/htop/htop.mk
@@ -7,7 +7,9 @@
HTOP_VERSION = 2.0.2
HTOP_SITE = http://hisham.hm/htop/releases/$(HTOP_VERSION)
HTOP_DEPENDENCIES = ncurses
+ifeq ($(BR2_PACKAGE_NCURSES_WCHAR),)
HTOP_CONF_OPTS = --disable-unicode
+endif
# Prevent htop build system from searching the host paths
HTOP_CONF_ENV = HTOP_NCURSES_CONFIG_SCRIPT=$(STAGING_DIR)/usr/bin/ncurses5-config
HTOP_LICENSE = GPLv2
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()
From: Jani Nikula @ 2016-11-09 9:27 UTC (permalink / raw)
To: Matt Roper, Paulo Zanoni; +Cc: Vetter, Daniel, intel-gfx
In-Reply-To: <20161109011315.GF6536@intel.com>
On Wed, 09 Nov 2016, Matt Roper <matthew.d.roper@intel.com> wrote:
> On Tue, Nov 08, 2016 at 03:21:22PM -0200, Paulo Zanoni wrote:
>> One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB
>> partitioning for multi-screen cases"), and the other was added by
>> 01c72d6c17 ("drm/i915/gen9: fix DDB partitioning for multi-screen
>> cases"). I'm confused and I'll let the maintainers find out what went
>> wrong here.
>>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> I think this is just an artifact of having the patch in both -next and
> -fixes. The context probably changed later in -next causing a conflict
> when the two were merged, and then the merge resolution accidentally
> duplicated this hunk. The merge commit ac4139ed7 is where we wound up
> with the two copies:
I don't have that merge commit. Is that a nightly rebuild?
I don't think we even have this issue in anywhere other than
nightly. There isn't a branch we could apply this fix to.
BR,
Jani.
>
> diff --cc drivers/gpu/drm/i915/intel_pm.c
> index db24f89,cc9e0c0..88e28c9
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@@ -3361,11 -3404,13 +3404,17 @@@ skl_allocate_pipe_ddb(struct intel_crtc
> unsigned int total_data_rate;
> int num_active;
> int id, i;
> + unsigned plane_data_rate[I915_MAX_PLANES] = {};
> + unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
> +
> + /* Clear the partitioning for disabled planes. */
> + memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> + memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
>
> + /* Clear the partitioning for disabled planes. */
> + memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> + memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
> +
> if (WARN_ON(!state))
> return 0;
>
> Dropping one looks good to me.
>
> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
>
>> ---
>> drivers/gpu/drm/i915/intel_pm.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
>> index 88e28c9..cc9e0c0 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -3411,10 +3411,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>> memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
>> memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
>>
>> - /* Clear the partitioning for disabled planes. */
>> - memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
>> - memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
>> -
>> if (WARN_ON(!state))
>> return 0;
>>
>> --
>> 2.7.4
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ 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.