* [PATCH] ARM: dts: sunxi: Convert to CCU index macros for HDMI controller
From: Maxime Ripard @ 2017-12-05 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204084401.2646-1-wens@csie.org>
Hi,
On Mon, Dec 04, 2017 at 04:44:01PM +0800, Chen-Yu Tsai wrote:
> When the HDMI controller device node was added, the needed PLL clock
> macros were not exported. A separate patch addresses that, but it is
> merged through a different tree.
>
> Now that both patches are in mainline proper, we can convert the raw
> numbers to proper macros.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/5353fceb/attachment.sig>
^ permalink raw reply
* [RESEND][PATCH] pwm: Set class for exported channels in sysfs
From: Thierry Reding @ 2017-12-05 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1496397921-1713-1-git-send-email-gottfried.haider@gmail.com>
On Fri, Jun 02, 2017 at 10:05:21AM +0000, Gottfried Haider wrote:
> Notifications for devices without bus or class set get dropped by
> dev_uevent_filter. Adding the class to the exported child matches
> what the gpio subsystem is doing.
>
> With this change exporting a channel triggers a udev event, which
> gives userspace a chance to fixup permissions and makes it possible
> for non-root users to make use of the pwm subsystem.
>
> Signed-off-by: Gottfried Haider <gottfried.haider@gmail.com>
> CC: Thierry Reding <thierry.reding@gmail.com>
> CC: H Hartley Sweeten <hsweeten@visionengravers.com>
> CC: linux-pwm at vger.kernel.org
> CC: linux-arm-kernel at lists.infradead.org
> CC: linux-rpi-kernel at lists.infradead.org
> ---
> drivers/pwm/sysfs.c | 1 +
> 1 file changed, 1 insertion(+)
Sorry for the long delay, applied to for-next now.
Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/5ba41b60/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 2/2] arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3
From: Maxime Ripard @ 2017-12-05 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512363187-8353-2-git-send-email-jagan@amarulasolutions.com>
On Mon, Dec 04, 2017 at 10:23:07AM +0530, Jagan Teki wrote:
> Since current tree support AXP803 regulators,
> replace fixed regulator vcc3v3 with AXP803 dcdc1 regulator where ever
> it need to replace.
>
> Tested mmc0 on sopine baseboard.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Queued as a fix, thanks
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/7751c46d/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: a64-olinuxino: Enable RTL8723BS WiFi
From: Maxime Ripard @ 2017-12-05 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512363187-8353-1-git-send-email-jagan@amarulasolutions.com>
On Mon, Dec 04, 2017 at 10:23:06AM +0530, Jagan Teki wrote:
> Enable RTL8723BS WiFi chip on a64-olinuxino board:
> - WiFi SDIO interface is connected to MMC1
> - WiFi REG_ON pin connected to gpio PL2: attach to mmc-pwrseq
> - WiFi HOST_WAKE pin connected to gpio PL3
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/e6b2cd13/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/3] mtd: nand: squash struct nand_buffers into struct nand_chip
From: Masahiro Yamada @ 2017-12-05 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512463636-28934-1-git-send-email-yamada.masahiro@socionext.com>
struct nand_buffers is malloc'ed in nand_scan_tail() just for
containing three pointers. Squash this struct into nand_chip.
Move and rename as follows:
chip->buffers->ecccalc -> chip->ecc.calc_buf
chip->buffers->ecccode -> chip->ecc.code_buf
chip->buffers->databuf -> chip->data_buf
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- Rename as Boris suggested
- Based on cafe_nand rework
drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
drivers/mtd/nand/denali.c | 2 +-
drivers/mtd/nand/fsmc_nand.c | 4 +-
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 4 +-
drivers/mtd/nand/nand_base.c | 91 ++++++++++++++--------------------
drivers/mtd/nand/nand_bbt.c | 2 +-
drivers/mtd/nand/omap2.c | 10 ++--
drivers/mtd/nand/sunxi_nand.c | 6 +--
include/linux/mtd/rawnand.h | 23 +++------
9 files changed, 59 insertions(+), 85 deletions(-)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
index e0eb51d..cc13c88 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1681,7 +1681,7 @@ static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
int ret;
if (!buf) {
- buf = chip->buffers->databuf;
+ buf = chip->data_buf;
/* Invalidate page cache */
chip->pagebuf = -1;
}
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 2fc964b..3e61ac4 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -328,7 +328,7 @@ static int denali_check_erased_page(struct mtd_info *mtd,
unsigned long uncor_ecc_flags,
unsigned int max_bitflips)
{
- uint8_t *ecc_code = chip->buffers->ecccode;
+ uint8_t *ecc_code = chip->ecc.code_buf;
int ecc_steps = chip->ecc.steps;
int ecc_size = chip->ecc.size;
int ecc_bytes = chip->ecc.bytes;
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index eac15d9..574b043 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -684,8 +684,8 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
uint8_t *p = buf;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
- uint8_t *ecc_code = chip->buffers->ecccode;
+ uint8_t *ecc_calc = chip->ecc.calc_buf;
+ uint8_t *ecc_code = chip->ecc.code_buf;
int off, len, group = 0;
/*
* ecc_oob is intentionally taken as uint16_t. In 16bit devices, we
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 50f8d4a..a760ae7 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1712,7 +1712,7 @@ static int mx23_check_transcription_stamp(struct gpmi_nand_data *this)
unsigned int search_area_size_in_strides;
unsigned int stride;
unsigned int page;
- uint8_t *buffer = chip->buffers->databuf;
+ uint8_t *buffer = chip->data_buf;
int saved_chip_number;
int found_an_ncb_fingerprint = false;
@@ -1771,7 +1771,7 @@ static int mx23_write_transcription_stamp(struct gpmi_nand_data *this)
unsigned int block;
unsigned int stride;
unsigned int page;
- uint8_t *buffer = chip->buffers->databuf;
+ uint8_t *buffer = chip->data_buf;
int saved_chip_number;
int status;
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 0cc61b1..fe583e4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1456,8 +1456,8 @@ static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
uint8_t *p = buf;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
- uint8_t *ecc_code = chip->buffers->ecccode;
+ uint8_t *ecc_calc = chip->ecc.calc_buf;
+ uint8_t *ecc_code = chip->ecc.code_buf;
unsigned int max_bitflips = 0;
chip->ecc.read_page_raw(mtd, chip, buf, 1, page);
@@ -1529,7 +1529,7 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
/* Calculate ECC */
for (i = 0; i < eccfrag_len ; i += chip->ecc.bytes, p += chip->ecc.size)
- chip->ecc.calculate(mtd, p, &chip->buffers->ecccalc[i]);
+ chip->ecc.calculate(mtd, p, &chip->ecc.calc_buf[i]);
/*
* The performance is faster if we position offsets according to
@@ -1563,7 +1563,7 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
chip->read_buf(mtd, &chip->oob_poi[aligned_pos], aligned_len);
}
- ret = mtd_ooblayout_get_eccbytes(mtd, chip->buffers->ecccode,
+ ret = mtd_ooblayout_get_eccbytes(mtd, chip->ecc.code_buf,
chip->oob_poi, index, eccfrag_len);
if (ret)
return ret;
@@ -1572,13 +1572,13 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
for (i = 0; i < eccfrag_len ; i += chip->ecc.bytes, p += chip->ecc.size) {
int stat;
- stat = chip->ecc.correct(mtd, p,
- &chip->buffers->ecccode[i], &chip->buffers->ecccalc[i]);
+ stat = chip->ecc.correct(mtd, p, &chip->ecc.code_buf[i],
+ &chip->ecc.calc_buf[i]);
if (stat == -EBADMSG &&
(chip->ecc.options & NAND_ECC_GENERIC_ERASED_CHECK)) {
/* check for empty pages with bitflips */
stat = nand_check_erased_ecc_chunk(p, chip->ecc.size,
- &chip->buffers->ecccode[i],
+ &chip->ecc.code_buf[i],
chip->ecc.bytes,
NULL, 0,
chip->ecc.strength);
@@ -1611,8 +1611,8 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
uint8_t *p = buf;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
- uint8_t *ecc_code = chip->buffers->ecccode;
+ uint8_t *ecc_calc = chip->ecc.calc_buf;
+ uint8_t *ecc_code = chip->ecc.code_buf;
unsigned int max_bitflips = 0;
for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
@@ -1674,8 +1674,8 @@ static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
uint8_t *p = buf;
- uint8_t *ecc_code = chip->buffers->ecccode;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
+ uint8_t *ecc_code = chip->ecc.code_buf;
+ uint8_t *ecc_calc = chip->ecc.calc_buf;
unsigned int max_bitflips = 0;
/* Read the OOB area first */
@@ -1894,7 +1894,7 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
/* Is the current page in the buffer? */
if (realpage != chip->pagebuf || oob) {
- bufpoi = use_bufpoi ? chip->buffers->databuf : buf;
+ bufpoi = use_bufpoi ? chip->data_buf : buf;
if (use_bufpoi && aligned)
pr_debug("%s: using read bounce buffer for buf@%p\n",
@@ -1938,7 +1938,7 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
/* Invalidate page cache */
chip->pagebuf = -1;
}
- memcpy(buf, chip->buffers->databuf + col, bytes);
+ memcpy(buf, chip->data_buf + col, bytes);
}
if (unlikely(oob)) {
@@ -1979,7 +1979,7 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
buf += bytes;
max_bitflips = max_t(unsigned int, max_bitflips, ret);
} else {
- memcpy(buf, chip->buffers->databuf + col, bytes);
+ memcpy(buf, chip->data_buf + col, bytes);
buf += bytes;
max_bitflips = max_t(unsigned int, max_bitflips,
chip->pagebuf_bitflips);
@@ -2403,7 +2403,7 @@ static int nand_write_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
int i, eccsize = chip->ecc.size, ret;
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
+ uint8_t *ecc_calc = chip->ecc.calc_buf;
const uint8_t *p = buf;
/* Software ECC calculation */
@@ -2433,7 +2433,7 @@ static int nand_write_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
int i, eccsize = chip->ecc.size, ret;
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
+ uint8_t *ecc_calc = chip->ecc.calc_buf;
const uint8_t *p = buf;
for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
@@ -2469,7 +2469,7 @@ static int nand_write_subpage_hwecc(struct mtd_info *mtd,
int oob_required, int page)
{
uint8_t *oob_buf = chip->oob_poi;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
+ uint8_t *ecc_calc = chip->ecc.calc_buf;
int ecc_size = chip->ecc.size;
int ecc_bytes = chip->ecc.bytes;
int ecc_steps = chip->ecc.steps;
@@ -2503,7 +2503,7 @@ static int nand_write_subpage_hwecc(struct mtd_info *mtd,
/* copy calculated ECC for whole page to chip->buffer->oob */
/* this include masked-value(0xFF) for unwritten subpages */
- ecc_calc = chip->buffers->ecccalc;
+ ecc_calc = chip->ecc.calc_buf;
ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
chip->ecc.total);
if (ret)
@@ -2737,9 +2737,9 @@ static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
if (part_pagewr)
bytes = min_t(int, bytes - column, writelen);
chip->pagebuf = -1;
- memset(chip->buffers->databuf, 0xff, mtd->writesize);
- memcpy(&chip->buffers->databuf[column], buf, bytes);
- wbuf = chip->buffers->databuf;
+ memset(chip->data_buf, 0xff, mtd->writesize);
+ memcpy(&chip->data_buf[column], buf, bytes);
+ wbuf = chip->data_buf;
}
if (unlikely(oob)) {
@@ -4632,7 +4632,6 @@ int nand_scan_tail(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd_to_nand(mtd);
struct nand_ecc_ctrl *ecc = &chip->ecc;
- struct nand_buffers *nbuf = NULL;
int ret, i;
/* New bad blocks should be marked in OOB, flash-based BBT, or both */
@@ -4646,30 +4645,22 @@ int nand_scan_tail(struct mtd_info *mtd)
return -EINVAL;
}
- nbuf = kzalloc(sizeof(*nbuf), GFP_KERNEL);
- if (!nbuf)
+ ecc->calc_buf = kmalloc(mtd->oobsize, GFP_KERNEL);
+ if (!ecc->calc_buf)
return -ENOMEM;
- nbuf->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
- if (!nbuf->ecccalc) {
+ ecc->code_buf = kmalloc(mtd->oobsize, GFP_KERNEL);
+ if (!ecc->code_buf) {
ret = -ENOMEM;
- goto err_free_nbuf;
+ goto err_free_buf;
}
- nbuf->ecccode = kmalloc(mtd->oobsize, GFP_KERNEL);
- if (!nbuf->ecccode) {
+ chip->data_buf = kmalloc(mtd->writesize + mtd->oobsize, GFP_KERNEL);
+ if (!chip->data_buf) {
ret = -ENOMEM;
- goto err_free_nbuf;
+ goto err_free_buf;
}
- nbuf->databuf = kmalloc(mtd->writesize + mtd->oobsize, GFP_KERNEL);
- if (!nbuf->databuf) {
- ret = -ENOMEM;
- goto err_free_nbuf;
- }
-
- chip->buffers = nbuf;
-
/*
* FIXME: some NAND manufacturer drivers expect the first die to be
* selected when manufacturer->init() is called. They should be fixed
@@ -4680,10 +4671,10 @@ int nand_scan_tail(struct mtd_info *mtd)
ret = nand_manufacturer_init(chip);
chip->select_chip(mtd, -1);
if (ret)
- goto err_free_nbuf;
+ goto err_free_buf;
/* Set the internal oob buffer location, just after the page data */
- chip->oob_poi = chip->buffers->databuf + mtd->writesize;
+ chip->oob_poi = chip->data_buf + mtd->writesize;
/*
* If no default placement scheme is given, select an appropriate one.
@@ -4969,13 +4960,10 @@ int nand_scan_tail(struct mtd_info *mtd)
err_nand_manuf_cleanup:
nand_manufacturer_cleanup(chip);
-err_free_nbuf:
- if (nbuf) {
- kfree(nbuf->databuf);
- kfree(nbuf->ecccode);
- kfree(nbuf->ecccalc);
- kfree(nbuf);
- }
+err_free_buf:
+ kfree(chip->data_buf);
+ kfree(ecc->code_buf);
+ kfree(ecc->calc_buf);
return ret;
}
@@ -5027,12 +5015,9 @@ void nand_cleanup(struct nand_chip *chip)
/* Free bad block table memory */
kfree(chip->bbt);
- if (chip->buffers) {
- kfree(chip->buffers->databuf);
- kfree(chip->buffers->ecccode);
- kfree(chip->buffers->ecccalc);
- kfree(chip->buffers);
- }
+ kfree(chip->data_buf);
+ kfree(chip->ecc.code_buf);
+ kfree(chip->ecc.calc_buf);
/* Free bad block descriptor memory */
if (chip->badblock_pattern && chip->badblock_pattern->options
diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 2915b67..3609285 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
@@ -898,7 +898,7 @@ static inline int nand_memory_bbt(struct mtd_info *mtd, struct nand_bbt_descr *b
{
struct nand_chip *this = mtd_to_nand(mtd);
- return create_bbt(mtd, this->buffers->databuf, bd, -1);
+ return create_bbt(mtd, this->data_buf, bd, -1);
}
/**
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index dad438c..7870cb1 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1530,7 +1530,7 @@ static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
const uint8_t *buf, int oob_required, int page)
{
int ret;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
+ uint8_t *ecc_calc = chip->ecccalc;
/* Enable GPMC ecc engine */
chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
@@ -1568,7 +1568,7 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
u32 data_len, const u8 *buf,
int oob_required, int page)
{
- u8 *ecc_calc = chip->buffers->ecccalc;
+ u8 *ecc_calc = chip->ecccalc;
int ecc_size = chip->ecc.size;
int ecc_bytes = chip->ecc.bytes;
int ecc_steps = chip->ecc.steps;
@@ -1605,7 +1605,7 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
/* copy calculated ECC for whole page to chip->buffer->oob */
/* this include masked-value(0xFF) for unwritten subpages */
- ecc_calc = chip->buffers->ecccalc;
+ ecc_calc = chip->ecccalc;
ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
chip->ecc.total);
if (ret)
@@ -1635,8 +1635,8 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
uint8_t *buf, int oob_required, int page)
{
- uint8_t *ecc_calc = chip->buffers->ecccalc;
- uint8_t *ecc_code = chip->buffers->ecccode;
+ uint8_t *ecc_calc = chip->ecccalc;
+ uint8_t *ecc_code = chip->ecccode;
int stat, ret;
unsigned int max_bitflips = 0;
diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 82244be..9fe5994 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1544,7 +1544,7 @@ static int sunxi_nfc_hw_common_ecc_read_oob(struct mtd_info *mtd,
chip->pagebuf = -1;
- return chip->ecc.read_page(mtd, chip, chip->buffers->databuf, 1, page);
+ return chip->ecc.read_page(mtd, chip, chip->data_buf, 1, page);
}
static int sunxi_nfc_hw_common_ecc_write_oob(struct mtd_info *mtd,
@@ -1557,8 +1557,8 @@ static int sunxi_nfc_hw_common_ecc_write_oob(struct mtd_info *mtd,
chip->pagebuf = -1;
- memset(chip->buffers->databuf, 0xff, mtd->writesize);
- ret = chip->ecc.write_page(mtd, chip, chip->buffers->databuf, 1, page);
+ memset(chip->data_buf, 0xff, mtd->writesize);
+ ret = chip->ecc.write_page(mtd, chip, chip->data_buf, 1, page);
if (ret)
return ret;
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 5b24a8e..254f847 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -520,6 +520,8 @@ static const struct nand_ecc_caps __name = { \
* @postpad: padding information for syndrome based ECC generators
* @options: ECC specific options (see NAND_ECC_XXX flags defined above)
* @priv: pointer to private ECC control data
+ * @calc_buf: buffer for calculated ECC, size is oobsize.
+ * @code_buf: buffer for ECC read from flash, size is oobsize.
* @hwctl: function to control hardware ECC generator. Must only
* be provided if an hardware ECC is available
* @calculate: function for ECC calculation or readback from ECC hardware
@@ -570,6 +572,8 @@ struct nand_ecc_ctrl {
int postpad;
unsigned int options;
void *priv;
+ u8 *calc_buf;
+ u8 *code_buf;
void (*hwctl)(struct mtd_info *mtd, int mode);
int (*calculate)(struct mtd_info *mtd, const uint8_t *dat,
uint8_t *ecc_code);
@@ -603,21 +607,6 @@ static inline int nand_standard_page_accessors(struct nand_ecc_ctrl *ecc)
}
/**
- * struct nand_buffers - buffer structure for read/write
- * @ecccalc: buffer pointer for calculated ECC, size is oobsize.
- * @ecccode: buffer pointer for ECC read from flash, size is oobsize.
- * @databuf: buffer pointer for data, size is (page size + oobsize).
- *
- * Do not change the order of buffers. databuf and oobrbuf must be in
- * consecutive order.
- */
-struct nand_buffers {
- uint8_t *ecccalc;
- uint8_t *ecccode;
- uint8_t *databuf;
-};
-
-/**
* struct nand_sdr_timings - SDR NAND chip timings
*
* This struct defines the timing requirements of a SDR NAND chip.
@@ -785,7 +774,6 @@ struct nand_manufacturer_ops {
* @setup_read_retry: [FLASHSPECIFIC] flash (vendor) specific function for
* setting the read-retry mode. Mostly needed for MLC NAND.
* @ecc: [BOARDSPECIFIC] ECC control structure
- * @buffers: buffer structure for read/write
* @buf_align: minimum buffer alignment required by a platform
* @hwcontrol: platform-specific hardware control structure
* @erase: [REPLACEABLE] erase function
@@ -825,6 +813,7 @@ struct nand_manufacturer_ops {
* @numchips: [INTERN] number of physical chips
* @chipsize: [INTERN] the size of one chip for multichip arrays
* @pagemask: [INTERN] page number mask = number of (pages / chip) - 1
+ * @data_buf: [INTERN] buffer for data, size is (page size + oobsize).
* @pagebuf: [INTERN] holds the pagenumber which is currently in
* data_buf.
* @pagebuf_bitflips: [INTERN] holds the bitflip count for the page which is
@@ -903,6 +892,7 @@ struct nand_chip {
int numchips;
uint64_t chipsize;
int pagemask;
+ u8 *data_buf;
int pagebuf;
unsigned int pagebuf_bitflips;
int subpagesize;
@@ -933,7 +923,6 @@ struct nand_chip {
struct nand_hw_control *controller;
struct nand_ecc_ctrl ecc;
- struct nand_buffers *buffers;
unsigned long buf_align;
struct nand_hw_control hwcontrol;
--
2.7.4
^ permalink raw reply related
* [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Mathias Nyman @ 2017-12-05 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <99ea0ee4-1fff-73df-d9b5-0f756dfc5635@codeaurora.org>
On 05.12.2017 04:54, Adam Wallis wrote:
> On 12/4/2017 9:15 PM, Chunfeng Yun wrote:
>> On Mon, 2017-12-04 at 09:27 -0500, Adam Wallis wrote:
>>> The xHCI driver currently has the IMOD set to 160, which
>>> translates to an IMOD interval of 40,000ns (160 * 250)ns
>>>
>>> Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
>>> introduced a QUIRK for the MTK platform to adjust this interval to 20,
>>> which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
>>> due to the fact that the MTK controller IMOD interval is 8 times
>>> as much as defined in xHCI spec.
>>>
>>> Instead of adding more quirk bits for additional platforms, this patch
>>> introduces the ability for vendors to set the IMOD_INTERVAL as is
>>> optimal for their platform. By using device_property_read_u32() on
>>> "imod-interval-ns", the IMOD INTERVAL can be specified in nano seconds.
>>> If no interval is specified, the default of 40,000ns (IMOD=160) will be
>>> used.
>>>
>>> No bounds checking has been implemented due to the fact that a vendor
>>> may have violated the spec and would need to specify a value outside of
>>> the max 8,000 IRQs/second limit specified in the xHCI spec.
>>>
>>> Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>>> Signed-off-by: Adam Wallis <awallis@codeaurora.org>
>>> ---
>>> changes from v3:
>>> * Changed imod-interval to imod-interval-ns [Rob Herring/Chunfeng]
>>> * Changed "modulation" to "moderation" throughout patch [Mathias]
>>> changes from v2:
>>> * Added PCI default value [Mathias]
>>> * Removed xhci-mtk.h from xhci-plat.c [Chunfeng Yun]
>>> * Removed MTK quirk from xhci-plat and moved logic to xhci-mtk [Chunfeng]
>>> * Updated bindings Documentation to use proper units [Rob Herring]
>>> * Added imod-interval description and example to MTK binding documentation
>>> changes from v1:
>>> * Removed device_property_read_u32() per suggestion from greg k-h
>>> * Used ER_IRQ_INTERVAL_MASK in place of (u16) cast
>>>
>>> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 2 ++
>>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>>> drivers/usb/host/xhci-mtk.c | 9 +++++++++
>>> drivers/usb/host/xhci-pci.c | 3 +++
>>> drivers/usb/host/xhci-plat.c | 5 +++++
>>> drivers/usb/host/xhci.c | 7 ++-----
>>> drivers/usb/host/xhci.h | 2 ++
>>> 7 files changed, 24 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> index 3059596..9ff5602 100644
>>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> @@ -46,6 +46,7 @@ Optional properties:
>>> - pinctrl-names : a pinctrl state named "default" must be defined
>>> - pinctrl-0 : pin control group
>>> See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>>> + - imod-interval-ns: default interrupt moderation interval is 5000ns
>>>
>>> Example:
>>> usb30: usb at 11270000 {
>>> @@ -66,6 +67,7 @@ usb30: usb at 11270000 {
>>> usb3-lpm-capable;
>>> mediatek,syscon-wakeup = <&pericfg>;
>>> mediatek,wakeup-src = <1>;
>>> + imod-interval-ns = <10000>;
>>> };
>>>
>>> 2nd: dual-role mode with xHCI driver
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> index ae6e484..969908d 100644
>>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> @@ -29,6 +29,7 @@ Optional properties:
>>> - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
>>> - usb3-lpm-capable: determines if platform is USB3 LPM capable
>>> - quirk-broken-port-ped: set if the controller has broken port disable mechanism
>>> + - imod-interval-ns: default interrupt moderation interval is 5000ns
>>>
>>> Example:
>>> usb at f0931000 {
>>> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
>>> index b62a1d2..1cb2a8b 100644
>>> --- a/drivers/usb/host/xhci-mtk.c
>>> +++ b/drivers/usb/host/xhci-mtk.c
>>> @@ -674,6 +674,15 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>>>
>>> xhci = hcd_to_xhci(hcd);
>>> xhci->main_hcd = hcd;
>>> +
>>> + /*
>>> + * imod_interval is the interrupt moderation value in nanoseconds.
>>> + * The increment interval is 8 times as much as that defined in
>>> + * the xHCI spec on MTK's controller.
>>> + */
>>> + xhci->imod_interval = 5000;
>>> + device_property_read_u32(dev, "imod-interval-ns", &xhci->imod_interval);
>>> +
>>> xhci->shared_hcd = usb_create_shared_hcd(driver, dev,
>>> dev_name(dev), hcd);
>>> if (!xhci->shared_hcd) {
>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>> index 7ef1274..4bcddd4 100644
>>> --- a/drivers/usb/host/xhci-pci.c
>>> +++ b/drivers/usb/host/xhci-pci.c
>>> @@ -234,6 +234,9 @@ static int xhci_pci_setup(struct usb_hcd *hcd)
>>> if (!xhci->sbrn)
>>> pci_read_config_byte(pdev, XHCI_SBRN_OFFSET, &xhci->sbrn);
>>>
>>> + /* imod_interval is the interrupt moderation value in nanoseconds. */
>>> + xhci->imod_interval = 40000;
>>> +
>>> retval = xhci_gen_setup(hcd, xhci_pci_quirks);
>>> if (retval)
>>> return retval;
>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>> index 09f164f..6f03830 100644
>>> --- a/drivers/usb/host/xhci-plat.c
>>> +++ b/drivers/usb/host/xhci-plat.c
>>> @@ -269,6 +269,11 @@ static int xhci_plat_probe(struct platform_device *pdev)
>>> if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
>>> xhci->quirks |= XHCI_BROKEN_PORT_PED;
>>>
>>> + /* imod_interval is the interrupt moderation value in nanoseconds. */
>>> + xhci->imod_interval = 40000;
>>> + device_property_read_u32(sysdev, "imod-interval-ns",
>>> + &xhci->imod_interval);
>>> +
>>> hcd->usb_phy = devm_usb_get_phy_by_phandle(sysdev, "usb-phy", 0);
>>> if (IS_ERR(hcd->usb_phy)) {
>>> ret = PTR_ERR(hcd->usb_phy);
>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>>> index 2424d30..0b7755b 100644
>>> --- a/drivers/usb/host/xhci.c
>>> +++ b/drivers/usb/host/xhci.c
>>> @@ -586,11 +586,8 @@ int xhci_run(struct usb_hcd *hcd)
>>> "// Set the interrupt modulation register");
>> s/modulation/moderation
>
> Mathias said there was no need to change the existing modulation strings - only
> the ones that I had added.
Baolu is working on a cleanup patch that removes debug messages that became
useless with debugfs and proper tracing support, including this line.
Less conflicts to resolve for me if we don't change this.
>
>>
>>> temp = readl(&xhci->ir_set->irq_control);
>>> temp &= ~ER_IRQ_INTERVAL_MASK;
>>> - /*
>>> - * the increment interval is 8 times as much as that defined
>>> - * in xHCI spec on MTK's controller
>>> - */
>>> - temp |= (u32) ((xhci->quirks & XHCI_MTK_HOST) ? 20 : 160);
>>> + temp |= (xhci->imod_interval / 250) & ER_IRQ_INTERVAL_MASK;
>>> +
>> No need a blank line
>
> If this patch goes through another version, I will remove this line
If Rob Acks this version I'll apply it and remove that blank line.
-Mathias
^ permalink raw reply
* [PATCH 0/3] pwm: meson-axg: add pwm controller driver
From: Thierry Reding @ 2017-12-05 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204060018.8856-1-yixun.lan@amlogic.com>
On Mon, Dec 04, 2017 at 02:00:15PM +0800, Yixun Lan wrote:
> This patch series try to add PWM controller driver for the
> Amlogic's Meson-AXG SoC. Update the Clock sources, pin DT.
>
> Jian Hu (3):
> dt-bindings: pwm: update bindings for the Meson-AXG
> pwm: meson: add clock source configuratin for Meson-AXG
Applied both of these, thanks.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/79d728d5/attachment.sig>
^ permalink raw reply
* [PATCH v4 02/10] pinctrl: axp209: add pinctrl features
From: Maxime Ripard @ 2017-12-05 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2207ddcb-21fc-e3e1-1a1c-11e11690a02e@free-electrons.com>
Hi,
On Mon, Dec 04, 2017 at 09:07:52AM +0100, Quentin Schulz wrote:
> >> +static int axp20x_pmx_set_mux(struct pinctrl_dev *pctldev,
> >> + unsigned int function, unsigned int group)
> >> +{
> >> + struct axp20x_gpio *gpio = pinctrl_dev_get_drvdata(pctldev);
> >> + unsigned int mask;
> >> +
> >> + /* Every pin supports GPIO_OUT and GPIO_IN functions */
> >> + if (function <= AXP20X_FUNC_GPIO_IN)
> >> + return axp20x_pmx_set(pctldev, group,
> >> + gpio->funcs[function].muxval);
> >> +
> >> + if (function == AXP20X_FUNC_LDO)
> >> + mask = gpio->desc->ldo_mask;
> >> + else
> >> + mask = gpio->desc->adc_mask;
> >
> > What is the point of this test...
> >
> >> + if (!(BIT(group) & mask))
> >> + return -EINVAL;
> >> +
> >> + /*
> >> + * We let the regulator framework handle the LDO muxing as muxing bits
> >> + * are basically also regulators on/off bits. It's better not to enforce
> >> + * any state of the regulator when selecting LDO mux so that we don't
> >> + * interfere with the regulator driver.
> >> + */
> >> + if (function == AXP20X_FUNC_LDO)
> >> + return 0;
> >
> > ... if you know that you're not going to do anything with one of the
> > outcomes. It would be better to just move that part above, instead of
> > doing the same test twice.
> >
>
> Return value is different. In one case, it is an error to request "ldo"
> for a pin that does not support it. In the other case, the ldo request
> is valid but nothing's done on driver side.
>
> Both cases are handled differently by the core:
> http://elixir.free-electrons.com/linux/latest/source/drivers/pinctrl/pinmux.c#L439
>
> I think that's the behavior we're expecting from this driver.
Ah, right.
> Or maybe you're asking to do:
>
> + if (function == AXP20X_FUNC_LDO) {
> + if (!(BIT(group) & gpio->desc->ldo_mask))
> + return -EINVAL;
> + return 0;
> + } else if (!(BIT(group) & gpio->desc->adc_mask)) {
> + return -EINVAL;
> + }
>
> ?
No, it's definitely better the way you did it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/c59bd573/attachment.sig>
^ permalink raw reply
* [PATCH v4 00/10] add pinmuxing support for pins in AXP209 and AXP813 PMICs
From: Maxime Ripard @ 2017-12-05 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaMxaLjsDETm6_56tyGDu6=W0L4SQCAA2mmSR4mkR-jAA@mail.gmail.com>
On Sat, Dec 02, 2017 at 05:00:03PM +0100, Linus Walleij wrote:
> On Fri, Dec 1, 2017 at 2:44 PM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
>
> > The AXP209 and AXP813 PMICs have several pins (respectively 3 and 2) that can
> > be used either as GPIOs or for other purposes (ADC or LDO here).
> >
> > We already have a GPIO driver for the GPIO use of those pins on the AXP209.
> > Let's "upgrade" this driver to support all the functions these pins can have.
> >
> > Then we add support to this driver for the AXP813 which is slighlty different
> > (basically a different offset in two registers and one less pin).
> >
> > I suggest patches 1 to 8 go through Linus's tree and 9 and 10 via Maxime or
> > Chen-Yu's tree.
> >
> > v4:
>
> Looks overall good. As soon as Maxime is happy with everything I will
> happily apply 1-8 to the pinctrl tree and then pull it to GPIO as well to
> avoid clashes.
>
> I think there were some minor comments but it seems almost finished.
You can apply everything with my
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The only comment left is the checkpatch warning, but there's multiple
occurences of that issue in the driver, so it can definitely be done
in a separate patch.
(But please do it Quentin ;))
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/f8fc76b8/attachment.sig>
^ permalink raw reply
* [PATCH] irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry
From: Marc Zyngier @ 2017-12-05 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <383ff5f3-44e9-e654-f421-2ac5bac2419a@codeaurora.org>
On 04/12/17 14:04, Shanker Donthineni wrote:
> Hi Thanks,
>
> On 12/04/2017 04:28 AM, Marc Zyngier wrote:
>> On 03/12/17 23:21, Shanker Donthineni wrote:
>>> As per MADT specification, it's perfectly valid firmware can pass
>>> MADT table to OS with disabled GICC entries. ARM64-SMP code skips
>>> those cpu cores to bring online. However the current GICv3 driver
>>> probe bails out in this case on systems where redistributor regions
>>> are not in the always-on power domain.
>>>
>>> This patch does the two things to fix the panic.
>>> - Don't return an error in gic_acpi_match_gicc() for disabled GICC.
>>> - No need to keep GICR region information for disabled GICC.
>>>
>>> Kernel crash traces:
>>> Kernel panic - not syncing: No interrupt controller found.
>>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26
>>> [<ffff000008087770>] dump_backtrace+0x0/0x218
>>> [<ffff0000080879dc>] show_stack+0x14/0x20
>>> [<ffff00000883b078>] dump_stack+0x98/0xb8
>>> [<ffff0000080c5c14>] panic+0x118/0x26c
>>> [<ffff000008b62348>] init_IRQ+0x24/0x2c
>>> [<ffff000008b609fc>] start_kernel+0x230/0x394
>>> [<ffff000008b601e4>] __primary_switched+0x64/0x6c
>>> ---[ end Kernel panic - not syncing: No interrupt controller found.
>>>
>>> Disabled GICC subtable example:
>>> Subtable Type : 0B [Generic Interrupt Controller]
>>> Length : 50
>>> Reserved : 0000
>>> CPU Interface Number : 0000003D
>>> Processor UID : 0000003D
>>> Flags (decoded below) : 00000000
>>> Processor Enabled : 0
>>> Performance Interrupt Trig Mode : 0
>>> Virtual GIC Interrupt Trig Mode : 0
>>> Parking Protocol Version : 00000000
>>> Performance Interrupt : 00000017
>>> Parked Address : 0000000000000000
>>> Base Address : 0000000000000000
>>> Virtual GIC Base Address : 0000000000000000
>>> Hypervisor GIC Base Address : 0000000000000000
>>> Virtual GIC Interrupt : 00000019
>>> Redistributor Base Address : 0000FFFF88F40000
>>> ARM MPIDR : 000000000000000D
>>> Efficiency Class : 00
>>> Reserved : 000000
>>>
>>> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
>>> ---
>>> drivers/irqchip/irq-gic-v3.c | 14 +++++++++-----
>>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>>> index b56c3e2..a30fbac 100644
>>> --- a/drivers/irqchip/irq-gic-v3.c
>>> +++ b/drivers/irqchip/irq-gic-v3.c
>>> @@ -1331,6 +1331,10 @@ static int __init gic_of_init(struct device_node *node, struct device_node *pare
>>> u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
>>> void __iomem *redist_base;
>>>
>>> + /* GICC entry which has !ACPI_MADT_ENABLED is not unusable so skip */
>>> + if (!(gicc->flags & ACPI_MADT_ENABLED))
>>> + return 0;
>>> +
>>> redist_base = ioremap(gicc->gicr_base_address, size);
>>> if (!redist_base)
>>> return -ENOMEM;
>>> @@ -1374,13 +1378,13 @@ static int __init gic_acpi_match_gicc(struct acpi_subtable_header *header,
>>> (struct acpi_madt_generic_interrupt *)header;
>>>
>>> /*
>>> - * If GICC is enabled and has valid gicr base address, then it means
>>> - * GICR base is presented via GICC
>>> + * If GICC is enabled and has not valid gicr base address, then it means
>>> + * GICR base is not presented via GICC
>>> */
>>> - if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address)
>>> - return 0;
>>> + if ((gicc->flags & ACPI_MADT_ENABLED) && (!gicc->gicr_base_address))
>>> + return -ENODEV;
>>
>> This doesn't feel quite right. It would mean that having the ENABLED
>> flag cleared and potentially no address would make it valid? It looks to
>> me that the original code is "less wrong".
>>
>> What am I missing?
>>
>
> Original definition of the function gic_acpi_match_gicc().
> {
> if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address)
> return 0;
>
> return -ENODEV;
> }
>
> Above code triggers the driver probe fail for the two reasons.
> 1) GICC with ACPI_MADT_ENABLED=0, it's a bug according to ACPI spec.
> 2) GICC with ACPI_MADT_ENABLED=1 and invalid GICR address, expected.
>
>
> This patch fix the first failed case and keep the second case intact.
> if ((gicc->flags & ACPI_MADT_ENABLED) && (!gicc->gicr_base_address))
> return -ENODEV;
>
> return 0;
If (1) is a firmware bug, then why is it handled in the SMP code? You're
even saying that this is the right thing to do?
As for (2), you seem to imply that only the address matter. So why isn't
it just:
if (gicc->gicr_base_address)
return 0;
?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] drivers: pwm: pwm-atmel: implement suspend/resume functions
From: Thierry Reding @ 2017-12-05 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170411115311.70a7239b@bbrezillon>
On Tue, Apr 11, 2017 at 11:53:11AM +0200, Boris Brezillon wrote:
> On Tue, 11 Apr 2017 12:41:59 +0300
> m18063 <Claudiu.Beznea@microchip.com> wrote:
>
> > On 11.04.2017 11:56, Boris Brezillon wrote:
> > > On Tue, 11 Apr 2017 11:22:39 +0300
> > > m18063 <Claudiu.Beznea@microchip.com> wrote:
> > >
> > >> Hi Boris,
> > >>
> > >> On 10.04.2017 17:35, Boris Brezillon wrote:
> > >>> On Mon, 10 Apr 2017 17:20:20 +0300
> > >>> Claudiu Beznea <claudiu.beznea@microchip.com> wrote:
> > >>>
> > >>>> Implement suspend and resume power management specific
> > >>>> function to allow PWM controller to correctly suspend
> > >>>> and resume.
> > >>>>
> > >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> > >>>> ---
> > >>>> drivers/pwm/pwm-atmel.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
> > >>>> 1 file changed, 81 insertions(+)
> > >>>>
> > >>>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> > >>>> index 530d7dc..75177c6 100644
> > >>>> --- a/drivers/pwm/pwm-atmel.c
> > >>>> +++ b/drivers/pwm/pwm-atmel.c
> > >>>> @@ -58,6 +58,8 @@
> > >>>> #define PWM_MAX_PRD 0xFFFF
> > >>>> #define PRD_MAX_PRES 10
> > >>>>
> > >>>> +#define PWM_MAX_CH_NUM (4)
> > >>>> +
> > >>>> struct atmel_pwm_registers {
> > >>>> u8 period;
> > >>>> u8 period_upd;
> > >>>> @@ -65,11 +67,18 @@ struct atmel_pwm_registers {
> > >>>> u8 duty_upd;
> > >>>> };
> > >>>>
> > >>>> +struct atmel_pwm_pm_ctx {
> > >>>> + u32 cmr;
> > >>>> + u32 cdty;
> > >>>> + u32 cprd;
> > >>>> +};
> > >>>> +
> > >>>> struct atmel_pwm_chip {
> > >>>> struct pwm_chip chip;
> > >>>> struct clk *clk;
> > >>>> void __iomem *base;
> > >>>> const struct atmel_pwm_registers *regs;
> > >>>> + struct atmel_pwm_pm_ctx ctx[PWM_MAX_CH_NUM];
> > >>>
> > >>> Hm, I'm pretty sure you can rely on the current PWM state and call
> > >>> atmel_pwm_apply() at resume time instead of doing that. See what I did
> > >>> here [1].
> > >>
> > >> I agree with the approach you propose but the thing is the atmel_pwm_apply()
> > >> take care of both, current PWM state and the new state received as argument
> > >> in order to change only duty factor without disabling the PWM channel (if
> > >> channel is enabled) and then returns. Changing PWM duty and period and polarity
> > >> in the same step without disabling + enabling the PWM channel (with atomic
> > >> approach) may lead to intermediary unwanted output waveforms (the IP doesn't
> > >> support this for ordinary PWM channels). To take advantage of atmel_pwm_apply()
> > >> (in the formit is today) in resume() hook might need to first call it to disable
> > >> channel and then to enable it. Or atmel_pwm_apply() should be changed to also
> > >> disable + enable the channel when user changes the duty factor at runtime.
> > >
> > > Nope. Just save the state at suspend time, implement ->get_state() and
> > > use it to retrieve the real PWM state when resuming before restoring
> > > the state you saved during suspend.
> > Ok.
> > > But anyway, as Thierry explained, I'm not sure we should take the
> > > 're-apply PWM state' action here. It's probably better to leave this
> > > decision to the PWM user.
> > Do you thinks we should proceed with restoring the registers behind
> > the re-apply as other drivers does at this moment?
>
> Nope. IMO we'd better start patching PWM users to restore the states
> rather than supporting suspend/resume in all PWM drivers.
>
> Thierry, what's your opinion?
I just noticed this thread while cleaning up patchwork. I think I had
already mentioned in an earlier reply that in my opinion we should leave
PWM suspend/resume to users.
I'm totally fine if we add helpers to the PWM core to help with that
task. Maybe something like this would work:
void pwm_suspend(struct pwm_device *pwm)
{
pwm_get_state(pwm, &pwm->suspend);
pwm_disable(pwm);
}
void pwm_resume(struct pwm_device *pwm)
{
pwm_apply_state(pwm, &pwm->suspend);
}
Though, quite frankly, this is so trivial that drivers could just do
that themselves. Also, the helpers above aren't flexible at all with
respect to any special sequences the PWM might need to go through on
suspend. I suspect that this doesn't matter at all in most cases but
given how trivial they are we might as well just make drivers do it.
Also we don't burden users that don't care about suspend/resume with
the extra suspend state in struct pwm_device.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/4db88999/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: h3: enable USB OTG for NanoPi Neo board
From: Maxime Ripard @ 2017-12-05 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201224942.GA12473@t440.localdomain>
Hi,
On Fri, Dec 01, 2017 at 11:49:42PM +0100, Krzysztof Adamski wrote:
> Similarly to Orange Pi Zero, NanoPi Neo board has an USB OTG port with
> an ID pin but with unpowered VBUS. This patch enables this port in
> forced peripheral mode.
>
> Signed-off-by: Krzysztof Adamski <k@japko.eu>
> ---
> arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
> index 78f6c24952dd..14c3f137dbd3 100644
> --- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
> @@ -53,3 +53,20 @@
> allwinner,leds-active-low;
> status = "okay";
> };
> +
> +&usb_otg {
> + status = "okay";
> + dr_mode = "peripheral";
> +};
> +
> +&usbphy {
> + usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
Please sort the nodes in alphabetical order.
Also, does it make sense to add the OHCI and EHCI controller for a
peripheral-only device?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/65c82fac/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] arm64: KVM: Move CPU ID reg trap setup off the world switch path
From: Christoffer Dall @ 2017-12-05 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512141582-17474-2-git-send-email-Dave.Martin@arm.com>
On Fri, Dec 01, 2017 at 03:19:40PM +0000, Dave Martin wrote:
> The HCR_EL2.TID3 flag needs to be set when trapping guest access to
> the CPU ID registers is required. However, the decision about
> whether to set this bit does not need to be repeated at every
> switch to the guest.
>
> Instead, it's sufficient to make this decision once and record the
> outcome.
>
> This patch moves the decision to vcpu_reset_hcr() and records the
> choice made in vcpu->arch.hcr_el2. The world switch code can then
> load this directly when switching to the guest without the need for
> conditional logic on the critical path.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Suggested-by: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> ---
>
> Note to maintainers: this was discussed on-list [1] prior to the merge
> window, but this patch implementing the agreed decision hasn't been
> posted previously.
>
> This should be considered a fix for v4.15.
It's actually easier for me to apply this for v4.16 and base my VHE
optimization patches on it.
Thanks,
-Christoffer
>
> [1] [PATCH v3 02/28] arm64: KVM: Hide unsupported AArch64 CPU features from guests
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/537420.html
> ---
> arch/arm64/include/asm/kvm_emulate.h | 8 ++++++++
> arch/arm64/kvm/hyp/switch.c | 4 ----
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 5f28dfa..8ff5aef 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -52,6 +52,14 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
> vcpu->arch.hcr_el2 |= HCR_E2H;
> if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
> vcpu->arch.hcr_el2 &= ~HCR_RW;
> +
> + /*
> + * TID3: trap feature register accesses that we virtualise.
> + * For now this is conditional, since no AArch32 feature regs
> + * are currently virtualised.
> + */
> + if (vcpu->arch.hcr_el2 & HCR_RW)
> + vcpu->arch.hcr_el2 |= HCR_TID3;
> }
>
> static inline unsigned long vcpu_get_hcr(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 525c01f..87fd590 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -86,10 +86,6 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
> write_sysreg(1 << 30, fpexc32_el2);
> isb();
> }
> -
> - if (val & HCR_RW) /* for AArch64 only: */
> - val |= HCR_TID3; /* TID3: trap feature register accesses */
> -
> write_sysreg(val, hcr_el2);
>
> /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: orange-pi-zero-plus2: fix sdcard detect
From: Maxime Ripard @ 2017-12-05 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171103195855.15283-2-geomatsi@gmail.com>
On Fri, Nov 03, 2017 at 10:58:54PM +0300, Sergey Matyukevich wrote:
> The sdcard detect pin on orange-pi-zero-plus2 is pulled up.
> Fix cd-gpio description to enable sdcard detect.
>
> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/80662e15/attachment.sig>
^ permalink raw reply
* [PATCH][v3] dt-bindings: ifc: Update endianness usage
From: Prabhakar Kushwaha @ 2017-12-05 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204204727.fnt4vsw2lg2q2w5x@rob-hp-laptop>
> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: Tuesday, December 05, 2017 2:17 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> Cc: devicetree at vger.kernel.org; mark.rutland at arm.com;
> shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH][v3] dt-bindings: ifc: Update endianness usage
>
> On Thu, Nov 30, 2017 at 01:36:36PM +0530, Prabhakar Kushwaha wrote:
> > IFC controller version < 2.0 support IFC register access as
> > big endian. These controller version also require IFC NOR signals to
> > be connected in reverse order with NOR flash.
> >
> > IFC >= 2.0 is other way around.
> >
> > So updating IFC binding to take care of both using endianness field.
> >
> > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> > ---
> > Changes for v2: updated subject
> > Changes for v3: fixed typo for "big-endian"
> >
> > Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > index 89427b0..824a2ca 100644
> > --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > @@ -18,8 +18,10 @@ Properties:
> > interrupt (NAND_EVTER_STAT). If there is only one,
> > that interrupt reports both types of event.
> >
> > -- little-endian : If this property is absent, the big-endian mode will
> > - be in use as default for registers.
> > +- little-endian or big-endian : It represents how IFC registers to be accessed.
> > + It also represents connection between controller and
> > + NOR flash. If this property is absent, the big-endian
> > + mode will be in use as default.
>
> My question on the prior version remains. I think if you need to handle
> more than just register endianness, that should be done with the
> compatible string.
>
I may not able to use compatible string as this information will also be used it drivers/mtd/maps/physmap_of_core.c other than drivers/memory/fsl_ifc.c.
I am trying to avoid controller specific details in generic file.
This is the reason endianness property is being used.
--prabhakar
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: Add configs for peripherals on Keystone2 SoCs
From: Vignesh R @ 2017-12-05 9:19 UTC (permalink / raw)
To: linux-arm-kernel
Enable Cadence QSPI present on 66AK2G SoC and Keystone USB PHY driver
for K2E.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 992a8a5da065..c4f4f6682ea5 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -185,6 +185,7 @@ CONFIG_MTD_NAND_BRCMNAND=y
CONFIG_MTD_NAND_VF610_NFC=y
CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_CADENCE_QUADSPI=m
CONFIG_SPI_FSL_QUADSPI=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
@@ -675,6 +676,7 @@ CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_USB_ISP1760=y
CONFIG_USB_HSIC_USB3503=y
CONFIG_AB8500_USB=y
+CONFIG_KEYSTONE_USB_PHY=m
CONFIG_NOP_USB_XCEIV=m
CONFIG_USB_GPIO_VBUS=y
CONFIG_USB_ISP1301=y
--
2.15.1
^ permalink raw reply related
* [linux-sunxi] [PATCH v4 09/10] ARM: dtsi: axp81x: add GPIO DT node
From: Chen-Yu Tsai @ 2017-12-05 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af90c57ebf97c8f5504a4b5b1dad3638bedadfef.1512135804.git-series.quentin.schulz@free-electrons.com>
On Fri, Dec 1, 2017 at 9:44 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This adds DT node for the GPIO/pinctrl part present in AXP813/AXP818.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> arch/arm/boot/dts/axp81x.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
> index 73b761f..0ef959d 100644
> --- a/arch/arm/boot/dts/axp81x.dtsi
> +++ b/arch/arm/boot/dts/axp81x.dtsi
> @@ -48,6 +48,12 @@
> interrupt-controller;
> #interrupt-cells = <1>;
>
> + axp_gpio: axp-gpio {
> + compatible = "x-powers,axp813-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
What about interrupt-controller for directly referenced interrupts from
the GPIO pins?
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> + };
> +
> regulators {
> /* Default work frequency for buck regulators */
> x-powers,dcdc-freq = <3000>;
> --
> git-series 0.9.1
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v4 10/10] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs
From: Chen-Yu Tsai @ 2017-12-05 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201155808.rxgp7pz7nmr6tab7@flea.lan>
On Fri, Dec 1, 2017 at 11:58 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Fri, Dec 01, 2017 at 02:44:51PM +0100, Quentin Schulz wrote:
>> On AXP813/818, GPIO0 and GPIO1 can be used as LDO as (respectively)
>> ldo_io0 and ldo_io1.
>>
>> Let's add the pinctrl properties to the said regulators.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [linux-sunxi] [PATCH v4 09/10] ARM: dtsi: axp81x: add GPIO DT node
From: Maxime Ripard @ 2017-12-05 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65mOwNBdit=gKOq0=iv94FNuH__4yvCw4v0NHYiCKccBw@mail.gmail.com>
Hi,
On Tue, Dec 05, 2017 at 05:24:47PM +0800, Chen-Yu Tsai wrote:
> On Fri, Dec 1, 2017 at 9:44 PM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
> > This adds DT node for the GPIO/pinctrl part present in AXP813/AXP818.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> > ---
> > arch/arm/boot/dts/axp81x.dtsi | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
> > index 73b761f..0ef959d 100644
> > --- a/arch/arm/boot/dts/axp81x.dtsi
> > +++ b/arch/arm/boot/dts/axp81x.dtsi
> > @@ -48,6 +48,12 @@
> > interrupt-controller;
> > #interrupt-cells = <1>;
> >
> > + axp_gpio: axp-gpio {
> > + compatible = "x-powers,axp813-gpio";
> > + gpio-controller;
> > + #gpio-cells = <2>;
>
> What about interrupt-controller for directly referenced interrupts from
> the GPIO pins?
There's a bit more to it to enable interrupts. You would probably need
to set up a chained interrupt controller in the GPIO driver, and in
the DTS with a interrupt-parent and interrupts properties pointing to
the AXP device itself.
> Otherwise,
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Applied 9 and 10, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/19eb2779/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] arm64/sve: KVM: Avoid dereference of dead task during guest entry
From: Christoffer Dall @ 2017-12-05 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204153648.GV22781@e103592.cambridge.arm.com>
Hi Dave,
On Mon, Dec 04, 2017 at 03:36:50PM +0000, Dave Martin wrote:
> On Mon, Dec 04, 2017 at 01:53:21PM +0000, Ard Biesheuvel wrote:
> > On 1 December 2017 at 15:19, Dave Martin <Dave.Martin@arm.com> wrote:
> > > When deciding whether to invalidate FPSIMD state cached in the cpu,
> > > the backend function sve_flush_cpu_state() attempts to dereference
> > > __this_cpu_read(fpsimd_last_state). However, this is not safe:
> > > there is no guarantee that the pointer is still valid, because the
> > > task could have exited in the meantime. For this reason, this
> > > percpu pointer should only be assigned or compared, never
> > > dereferenced.
> > >
> >
> > Doesn't that mean the pointer could also be pointing to the
> > fpsimd_state of a newly created task that is completely unrelated?
> > IOW, are you sure comparison is safe?
>
> There are more conditions: the only place the determination is
> made is for next, in fpsimd_thread_switch(next).
>
>
> However, I can see your concern and I'm not sure how/if it is
> resolved.
>
> For the worst case, let's assume that some child forks off but
> doesn't enter userspace yet, while another task round-robins
> across all CPUs, interspersed with tasks that don't enter userspace.
>
> So, we end up with
>
> All cpu < NR_CPUS . per_cpu(fpsimd_last_state, cpu) == T.
>
> Now, if T dies and a new task is allocated the same task_struct pointer,
> then the _new_ T is guaranteed to get scheduled in on a CPU whose
> per_cpu(fpsmid_last_state) == T.
>
> Thus, new T can pick up old T's regs _unless_ new T's fpsimd_state.cpu
> is invalid (i.e., NR_CPUS).
>
> This is a separate bug from the one addressed by this patch though.
> We can't go and harvest the bad pointers when old T exits, because
> this might race new T being scheduled for real -- in any case it
> would involve iterating over all CPUs which sounds racy and
> inefficient.
>
>
> So, I'd say we _must_ call fpsimd_flush_task_state() for every new
> task. This may result in a redundant reload of the state, but this
> is what would happen anyway if the pointers did not alias.
>
> Does this sound real to you? If so, I'll try to write something.
>
> And does this patch look reasonable to fix what it's trying to fix?
>
>
> I wonder whether arch/arm has the same bug actually, since the kernel-
> mode NEON logic was modelled from there IIUC (?)
>
Isn't this the common kernel problem of pid reuse?
It seems holding a reference to a struct pid would solve your problems.
See include/linux/pid.h.
That might also make the code more intuitive and prevent future attempts
of dereferencing potentially dead data structures.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] ARM: Disable CONFIG_DEBUG_VIRTUAL for NOMMU
From: Vladimir Murzin @ 2017-12-05 9:53 UTC (permalink / raw)
To: linux-arm-kernel
While running MPS2 platform (NOMMU) with DTB placed below PHYS_OFFSET
following warning poped up:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at arch/arm/mm/physaddr.c:42 __virt_to_phys+0x2f/0x40
virt_to_phys used for non-linear address: 00004000 (0x4000)
CPU: 0 PID: 0 Comm: swapper Not tainted 4.15.0-rc1-5a31bf2-clean+ #2767
Hardware name: MPS2 (Device Tree Support)
[<2100bf39>] (unwind_backtrace) from [<2100b3ff>] (show_stack+0xb/0xc)
[<2100b3ff>] (show_stack) from [<2100e697>] (__warn+0x87/0xac)
[<2100e697>] (__warn) from [<2100e6db>] (warn_slowpath_fmt+0x1f/0x28)
[<2100e6db>] (warn_slowpath_fmt) from [<2100c603>] (__virt_to_phys+0x2f/0x40)
[<2100c603>] (__virt_to_phys) from [<2116a499>] (early_init_fdt_reserve_self+0xd/0x24)
[<2116a499>] (early_init_fdt_reserve_self) from [<2116222d>] (arm_memblock_init+0xb5/0xf8)
[<2116222d>] (arm_memblock_init) from [<21161cad>] (setup_arch+0x38b/0x50e)
[<21161cad>] (setup_arch) from [<21160455>] (start_kernel+0x31/0x280)
[<21160455>] (start_kernel) from [<00000000>] ( (null))
random: get_random_bytes called from init_oops_id+0x17/0x2c with crng_init=0
---[ end trace 0000000000000000 ]---
Platforms without MMU support run with 1:1 (i.e. linear) memory
mapping, so disable CONFIG_DEBUG_VIRTUAL.
Fixes: e377cd8221eb ("ARM: 8640/1: Add support for CONFIG_DEBUG_VIRTUAL")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
KernelVersion: 4.15-rc1
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 18c1e7d..6cd616b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -4,7 +4,7 @@ config ARM
default y
select ARCH_CLOCKSOURCE_DATA
select ARCH_DISCARD_MEMBLOCK if !HAVE_ARCH_PFN_VALID
- select ARCH_HAS_DEBUG_VIRTUAL
+ select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_SET_MEMORY
--
2.0.0
^ permalink raw reply related
* [PATCH 0/7 v2] net: Fix platform_get_irq's error checking
From: Sergei Shtylyov @ 2017-12-05 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512409703-20881-1-git-send-email-arvind.yadav.cs@gmail.com>
On 12/4/2017 8:48 PM, Arvind Yadav wrote:
> The platform_get_irq() function returns negative number if an error
> occurs, Zero if No irq is found and positive number if irq gets successful.
No, returning 0 is not a failure indication anymore. It used to be but not
any longer...
> platform_get_irq() error checking for only zero is not correct.
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH 0/7 v2] net: Fix platform_get_irq's error checking
From: Sergei Shtylyov @ 2017-12-05 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4b55643-2f28-d684-0603-83c6f336a23b@cogentembedded.com>
On 12/5/2017 12:54 PM, Sergei Shtylyov wrote:
>> The platform_get_irq() function returns negative number if an error
>> occurs, Zero if No irq is found and positive number if irq gets successful.
>
> ?? No, returning 0 is not a failure indication anymore! It used to be but not
> any longer...
And I fixed this function exactly to avoid overly complex error checks
(which you're trying to propose here).
>> platform_get_irq() error checking for only zero is not correct.
>
> [...]
MBR, Sergei
^ permalink raw reply
* [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
From: Gary Lin @ 2017-12-05 10:01 UTC (permalink / raw)
To: linux-arm-kernel
The series of patches introduce Security Version to EFI stub.
Security Version is a monotonically increasing number and designed to
prevent the user from loading an insecure kernel accidentally. The
bootloader maintains a list of security versions corresponding to
different distributions. After fixing a critical vulnerability, the
distribution kernel maintainer bumps the "version", and the bootloader
updates the list automatically. When the user tries to load a kernel
with a lower security version, the bootloader shows a warning prompt
to notify the user the potential risk.
For more details: https://github.com/lcp/shim/wiki/Security-Version
The original idea is to add a new PE/COFF section to store the data.
However, there are some restrictions.
1. For x86, the size limit of the EFI header is 0x200, and a section entry
in the section table takes 40 bytes. Currently, the EFI header already
occupies the first 0x1da bytes, so there is no room for a new section
entry.
2. The MemoryAttributes table sets the attributes of memory pages according
to the section flags. For ARM64, the minimal granularity is 4KB, but
Security Version only needs a few bytes, and it's pointless to allocate
4KB for it.
Fortunately, there is a special section defined in PE/COFF: resource
section. The only known user of the resource section in UEFI is the HII
protocol which fetches data from "HII" directory. For Security Version, a
new directory called "LinuxSV" is created and it contains the file offset
to the struct of Security Version. The bootloader just follows the
resource table to fetch the "version" from the image file.
v3:
- Move everything to the resource section to be compatible with both
x86 and ARM64
v2:
- Decrease the size of secdata_offset to 2 bytes since the setup header
is limited to around 32KB.
- Restructure the secdata section. The signer is now a null-terminated
string. The type of distro_version changes to u32 in case the distro
uses a long version.
- Modify the Kconfig names and add help.
- Remove the signer name hack in build.c.
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Joey Lee <jlee@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
Gary Lin (2):
x86/efi: Introduce Security Version to x86
arm64/efi: Introduce Security Version to ARM64
arch/arm64/kernel/efi-header.S | 57 ++++++++++++++++++++++++++++++++++++++++++
arch/x86/boot/header.S | 55 ++++++++++++++++++++++++++++++++++++++++
drivers/firmware/efi/Kconfig | 40 +++++++++++++++++++++++++++++
3 files changed, 152 insertions(+)
--
2.15.0
^ permalink raw reply
* [RFC v3 PATCH 1/2] x86/efi: Introduce Security Version to x86
From: Gary Lin @ 2017-12-05 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205100148.5757-1-glin@suse.com>
Security Version is a mechanism based on UEFI Secure Boot to keep the
user from loading an insecure kernel accidentally. It's a monotonically
increasing number representing how "secure" the kernel is. The distro
kernel maintainer has to specify the distro name (signer) and the distro
version to distinguish the distro kernel among other kernel images. When
a critical vulnerability is fixed, the maintainer bumps Security Version,
and the bootloader (e.g. shim) records the Security Version in a UEFI
BootService variable. If the user tries to load a kernel with a lower
Security Version, the bootloader shows a warning prompt, and the user
decides whether to boot the kernel or not.
For the better portability, Security Version utilizes the resource
section(*) of PE/COFF to locate the struct of Security Version. The
resource section is a read-only section to index data in a binary-sorted
tree structure. The Windows images stores the resource data in a three
levels struture. For simplicity, we only use one level for Security
Version. A directory called "LinuxSV" is created and it contains the
offset to the struct of Security Version. The bootloader just follows
the resource table to fetch the details.
The struct of Security Version can be presented as the following:
struct sv_hdr {
__u16 header_length;
__u16 security_version;
__u32 distro_version;
} __attribute__((packed));
char *signer;
It consists of a fixed size structure and a null-terminated string.
"header_length" is the size of "struct sv_hdr". It's also used as a
kind of the "header version" in case a new member is introduced later.
(*) PE Format: The .rsrc Section
https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#the_.rsrc_section
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Joey Lee <jlee@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
---
| 55 ++++++++++++++++++++++++++++++++++++++++++++
drivers/firmware/efi/Kconfig | 40 ++++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+)
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 850b8762e889..dc1b80b29478 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -188,7 +188,12 @@ extra_header_fields:
.quad 0 # ExportTable
.quad 0 # ImportTable
+#ifdef CONFIG_SECURITY_VERSION_SUPPORT
+ .long rsrc_table # ResourceTable
+ .long rsrc_table_size
+#else
.quad 0 # ResourceTable
+#endif
.quad 0 # ExceptionTable
.quad 0 # CertificationTable
.quad 0 # BaseRelocationTable
@@ -634,3 +639,53 @@ die:
setup_corrupt:
.byte 7
.string "No setup signature found...\n"
+
+#ifdef CONFIG_SECURITY_VERSION_SUPPORT
+# Resource Table
+ .section ".rodata", "a", @progbits
+ .align 2
+rsrc_table:
+ # Resource Directory
+ .long 0 # Characteristics
+ .long 0 # TimeDateStamp
+ .short 0 # MajorVersion
+ .short 0 # MinorVersion
+ .short 1 # NumberOfNamedEntries
+ .short 0 # NumberOfIdEntries
+
+ # Resource Directory Entry
+ .long name_offset | 0x80000000 # NameOffset:31
+ # NameIsString:1
+ .long rsrc_data_entry - rsrc_table # OffsetToData
+
+ .set name_offset, . - rsrc_table
+ # Resource Directory String
+ .short 7 # Length
+ .short 0x4C00 # 'L'
+ .short 0x6900 # 'i'
+ .short 0x6E00 # 'n'
+ .short 0x7500 # 'u'
+ .short 0x7800 # 'x'
+ .short 0x5300 # 'S'
+ .short 0x5600 # 'V'
+
+ .set svdata_entry_offset, . - rsrc_table
+ # Resource Data Entry
+rsrc_data_entry:
+ .long svdata_begin # OffsetToData
+ .long svdata_end - svdata_begin # Size
+ .long 0 # CodePage
+ .long 0 # Reserved
+
+ .set rsrc_table_size, . - rsrc_table
+
+ # Security Version
+svdata_begin:
+ .short sv_signer - svdata_begin
+ .short CONFIG_SECURITY_VERSION
+ .long CONFIG_DISTRO_VERSION
+sv_signer:
+ .string CONFIG_SIGNER_NAME
+svdata_end:
+
+#endif /* CONFIG_SECURITY_VERSION_SUPPORT */
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 2b4c39fdfa91..1dd82f1dd094 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -161,6 +161,46 @@ config RESET_ATTACK_MITIGATION
still contains secrets in RAM, booting another OS and extracting the
secrets.
+menuconfig SECURITY_VERSION_SUPPORT
+ bool "Security Version Support" if EFI_STUB
+ help
+ The security version is the number defined by the distribution
+ to indicate the critical security fixes. The bootloader could
+ maintain a list of the security versions of the current kernels.
+ After fixing a severe vulnerability in the kernel, the distribution
+ bumps the security version to notify the bootloader to update
+ the list. If the user tries to load a kernel with a smaller security
+ version, the bootloadr could show a warning to the user to avoid
+ a vulnerable kernel from being loaded accidentally.
+
+ This is mainly designed for the distribution kernel maintainer.
+ Say N if you don't know what it is.
+
+
+config SIGNER_NAME
+ string "Signer Name" if SECURITY_VERSION_SUPPORT
+ depends on EFI && X86
+ default ""
+ help
+ This option specifies who signs or releases this kernel.
+
+config DISTRO_VERSION
+ int "Distribution Version" if SECURITY_VERSION_SUPPORT
+ depends on EFI && X86
+ default 0
+ range 0 4294967295
+ help
+ This option specifies the distribution version which this
+ kernel belongs to.
+
+config SECURITY_VERSION
+ int "Security Version" if SECURITY_VERSION_SUPPORT
+ depends on EFI && X86
+ default 0
+ range 0 65535
+ help
+ This option specifies the security version of this kernel.
+
endmenu
config UEFI_CPER
--
2.15.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox