Re: [PATCH 2/2] bcache: remove unused parameter
On 2016/11/25 上午9:40, Yijing Wang wrote:
> Parameter bio is no longer used, clean it.
>
> Signed-off-by: Yijing Wang
> ---
> drivers/md/bcache/request.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
> index 40ffe5e..bf6e432 100644
> --- a/drivers/md/bcache/request.c
> +++ b/drivers/md/bcache/request.c
> @@ -26,12 +26,12 @@ struct kmem_cache *bch_search_cache;
>
> static void bch_data_insert_start(struct closure *);
>
> -static unsigned cache_mode(struct cached_dev *dc, struct bio *bio)
> +static unsigned cache_mode(struct cached_dev *dc)
> {
> return BDEV_CACHE_MODE(&dc->sb);
> }
>
> -static bool verify(struct cached_dev *dc, struct bio *bio)
> +static bool verify(struct cached_dev *dc)
> {
> return dc->verify;
> }
> @@ -371,7 +371,7 @@ static struct hlist_head *iohash(struct cached_dev *dc,
> uint64_t k)
> static bool check_should_bypass(struct cached_dev *dc, struct bio *bio)
> {
> struct cache_set *c = dc->disk.c;
> - unsigned mode = cache_mode(dc, bio);
> + unsigned mode = cache_mode(dc);
> unsigned sectors, congested = bch_get_congested(c);
> struct task_struct *task = current;
> struct io *i;
> @@ -746,7 +746,7 @@ static void cached_dev_read_done(struct closure *cl)
> s->cache_miss = NULL;
> }
>
> - if (verify(dc, &s->bio.bio) && s->recoverable && !s->read_dirty_data)
> + if (verify(dc) && s->recoverable && !s->read_dirty_data)
> bch_data_verify(dc, s->orig_bio);
>
> bio_complete(s);
> @@ -771,7 +771,7 @@ static void cached_dev_read_done_bh(struct closure *cl)
>
> if (s->iop.error)
> continue_at_nobarrier(cl, cached_dev_read_error, bcache_wq);
> - else if (s->iop.bio || verify(dc, &s->bio.bio))
> + else if (s->iop.bio || verify(dc))
> continue_at_nobarrier(cl, cached_dev_read_done, bcache_wq);
> else
> continue_at_nobarrier(cl, cached_dev_bio_complete, NULL);
> @@ -898,7 +898,7 @@ static void cached_dev_write(struct cached_dev *dc,
> struct search *s)
> s->iop.bypass = true;
>
> if (should_writeback(dc, s->orig_bio,
> - cache_mode(dc, bio),
> + cache_mode(dc),
>s->iop.bypass)) {
> s->iop.bypass = false;
> s->iop.writeback = true;
>
Acked-by: Coly Li
--
Coly Li
[LINUX RFC v4 3/4] mtd: spi-nor: add stripe support
This patch adds stripe support and it is needed for GQSPI parallel
configuration mode by:
- Adding required parameters like stripe and shift to spi_nor
structure.
- Initializing all added parameters in spi_nor_scan()
- Updating read_sr() and read_fsr() for getting status from both
flashes
- Increasing page_size, sector_size, erase_size and toatal flash
size as and when required.
- Dividing address by 2
- Updating spi->master->flags for qspi driver to change CS
Signed-off-by: Naga Sureshkumar Relli
---
Changes for v4:
- rename isparallel to stripe
Changes for v3:
- No change
Changes for v2:
- Splitted to separate MTD layer changes from SPI core changes
---
drivers/mtd/spi-nor/spi-nor.c | 130 --
include/linux/mtd/spi-nor.h | 2 +
2 files changed, 103 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d0fc165..4252239 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/* Define max times to check status register before we give up. */
@@ -89,15 +90,24 @@ static const struct flash_info *spi_nor_match_id(const char
*name);
static int read_sr(struct spi_nor *nor)
{
int ret;
- u8 val;
+ u8 val[2];
- ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
- if (ret < 0) {
- pr_err("error %d reading SR\n", (int) ret);
- return ret;
+ if (nor->stripe) {
+ ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 2);
+ if (ret < 0) {
+ pr_err("error %d reading SR\n", (int) ret);
+ return ret;
+ }
+ val[0] |= val[1];
+ } else {
+ ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 1);
+ if (ret < 0) {
+ pr_err("error %d reading SR\n", (int) ret);
+ return ret;
+ }
}
- return val;
+ return val[0];
}
/*
@@ -108,15 +118,24 @@ static int read_sr(struct spi_nor *nor)
static int read_fsr(struct spi_nor *nor)
{
int ret;
- u8 val;
+ u8 val[2];
- ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
- if (ret < 0) {
- pr_err("error %d reading FSR\n", ret);
- return ret;
+ if (nor->stripe) {
+ ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 2);
+ if (ret < 0) {
+ pr_err("error %d reading FSR\n", ret);
+ return ret;
+ }
+ val[0] &= val[1];
+ } else {
+ ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 1);
+ if (ret < 0) {
+ pr_err("error %d reading FSR\n", ret);
+ return ret;
+ }
}
- return val;
+ return val[0];
}
/*
@@ -290,9 +309,16 @@ static int spi_nor_wait_till_ready(struct spi_nor *nor)
*/
static int erase_chip(struct spi_nor *nor)
{
+ u32 ret;
+
dev_dbg(nor->dev, " %lldKiB\n", (long long)(nor->mtd.size >> 10));
- return nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
+ ret = nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
+ if (ret)
+ return ret;
+
+ return ret;
+
}
static int spi_nor_lock_and_prep(struct spi_nor *nor, enum spi_nor_ops ops)
@@ -349,7 +375,7 @@ static int spi_nor_erase_sector(struct spi_nor *nor, u32
addr)
static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
- u32 addr, len;
+ u32 addr, len, offset;
uint32_t rem;
int ret;
@@ -399,9 +425,13 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
/* "sector"-at-a-time erase */
} else {
while (len) {
+
write_enable(nor);
+ offset = addr;
+ if (nor->stripe)
+ offset /= 2;
- ret = spi_nor_erase_sector(nor, addr);
+ ret = spi_nor_erase_sector(nor, offset);
if (ret)
goto erase_err;
@@ -525,6 +555,8 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs,
uint64_t len)
bool use_top;
int ret;
+ ofs = ofs >> nor->shift;
+
status_old = read_sr(nor);
if (status_old < 0)
return status_old;
@@ -610,6 +642,8 @@ static int stm_unlock(struct spi_nor *nor, loff_t ofs,
uint64_t len)
bool use_top;
int ret;
+ ofs = ofs >> nor->shift;
+
status_old = read_sr(nor);
if (status_old < 0)
return status_old;
@@ -709,6 +743,8 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs,
ui
[LINUX RFC v4 2/4] mtd: add spi_device instance to spi_nor struct
This patch adds struct spi_device instacne to the spi_nor structure.
Signed-off-by: Naga Sureshkumar Relli
---
Changes for v4:
- No change
Changes for v3:
- No change
Changes for v2:
- This is new patch, basically splitted on request of Mark Brown
---
drivers/mtd/devices/m25p80.c | 1 +
include/linux/mtd/spi-nor.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 9cf7fcd..58cfb42 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -219,6 +219,7 @@ static int m25p_probe(struct spi_device *spi)
spi_set_drvdata(spi, flash);
flash->spi = spi;
+ nor->spi = spi;
if (spi->mode & SPI_RX_QUAD)
mode = SPI_NOR_QUAD;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index c425c7b..84f3ce5 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -157,6 +157,7 @@ struct spi_nor {
struct mtd_info mtd;
struct mutexlock;
struct device *dev;
+ struct spi_device *spi;
u32 page_size;
u8 addr_width;
u8 erase_opcode;
--
2.10.2
[LINUX RFC v4 0/4] Add stripe support for ZynqMP SoC GQSPI controller
This patch series is continuation to previous patches mentioned in below link http://marc.info/?l=linux-spi&m=145009963109143&w=2 i am re-initiating this series, Could you please help us to get this done? what is dual parallel mode? --- ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities: 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. 2) Chip selects, data lines and clock are differ to both the flash devices 3) This mode is targeted for faster read/write speed and also doubles the size 4) Commands/data can be transmitted/received from both the devices(mirror), or only upper or only lower flash memory devices. 5) Data arrangement: With stripe enabled, Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. i have tested this on top of latest git-hub master. kindly suggest us the way, so that we can proceed further to add this support. Naga Sureshkumar Relli (4): spi: adding support for data stripe feature in core mtd: add spi_device instance to spi_nor struct mtd: spi-nor: add stripe support spi: zynqmp: gqspi: add support for stripe feature drivers/mtd/devices/m25p80.c | 1 + drivers/mtd/spi-nor/spi-nor.c | 130 - drivers/spi/spi-zynqmp-gqspi.c | 26 - drivers/spi/spi.c | 8 +++ include/linux/mtd/spi-nor.h| 3 + include/linux/spi/spi.h| 11 6 files changed, 149 insertions(+), 30 deletions(-) -- 2.10.2
[LINUX RFC v4 4/4] spi: zynqmp: gqspi: add support for stripe feature
This patch adds support of dual parallel mode configuration
for Zynq Ultrascale+ MPSoC GQSPI controller driver.
Signed-off-by: Naga Sureshkumar Relli
---
Changes for v4:
- No changes
Changes for v3:
- No change
Changes for v2:
- No change
---
drivers/spi/spi-zynqmp-gqspi.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 18aeace..dc7cf03 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -153,6 +153,7 @@ enum mode_type {GQSPI_MODE_IO, GQSPI_MODE_DMA};
* @dma_rx_bytes: Remaining bytes to receive by DMA mode
* @dma_addr: DMA address after mapping the kernel buffer
* @genfifoentry: Used for storing the genfifoentry instruction.
+ * @isinstr: To determine whether the transfer is instruction
* @mode: Defines the mode in which QSPI is operating
*/
struct zynqmp_qspi {
@@ -170,6 +171,7 @@ struct zynqmp_qspi {
u32 dma_rx_bytes;
dma_addr_t dma_addr;
u32 genfifoentry;
+ bool isinstr;
enum mode_type mode;
};
@@ -404,11 +406,24 @@ static void zynqmp_qspi_chipselect(struct spi_device
*qspi, bool is_high)
u32 genfifoentry = 0x0, statusreg;
genfifoentry |= GQSPI_GENFIFO_MODE_SPI;
+
+
+ if (qspi->master->flags & SPI_MASTER_BOTH_CS) {
+ zynqmp_gqspi_selectslave(xqspi,
+ GQSPI_SELECT_FLASH_CS_BOTH,
+ GQSPI_SELECT_FLASH_BUS_BOTH);
+ } else {
+ zynqmp_gqspi_selectslave(xqspi,
+ GQSPI_SELECT_FLASH_CS_LOWER,
+ GQSPI_SELECT_FLASH_BUS_LOWER);
+ }
+
genfifoentry |= xqspi->genfifobus;
if (!is_high) {
genfifoentry |= xqspi->genfifocs;
genfifoentry |= GQSPI_GENFIFO_CS_SETUP;
+ xqspi->isinstr = true;
} else {
genfifoentry |= GQSPI_GENFIFO_CS_HOLD;
}
@@ -665,6 +680,7 @@ static irqreturn_t zynqmp_qspi_irq(int irq, void *dev_id)
if ((xqspi->bytes_to_receive == 0) && (xqspi->bytes_to_transfer == 0)
&& ((status & GQSPI_IRQ_MASK) == GQSPI_IRQ_MASK)) {
zynqmp_gqspi_write(xqspi, GQSPI_IDR_OFST, GQSPI_ISR_IDR_MASK);
+ xqspi->isinstr = false;
spi_finalize_current_transfer(master);
ret = IRQ_HANDLED;
}
@@ -828,6 +844,9 @@ static int zynqmp_qspi_start_transfer(struct spi_master
*master,
genfifoentry |= xqspi->genfifocs;
genfifoentry |= xqspi->genfifobus;
+ if ((!xqspi->isinstr) && (master->flags & SPI_MASTER_DATA_STRIPE))
+ genfifoentry |= GQSPI_GENFIFO_STRIPE;
+
zynqmp_qspi_txrxsetup(xqspi, transfer, &genfifoentry);
if (xqspi->mode == GQSPI_MODE_DMA)
@@ -980,6 +999,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
struct zynqmp_qspi *xqspi;
struct resource *res;
struct device *dev = &pdev->dev;
+ u32 num_cs;
master = spi_alloc_master(&pdev->dev, sizeof(*xqspi));
if (!master)
@@ -1040,7 +1060,11 @@ static int zynqmp_qspi_probe(struct platform_device
*pdev)
goto clk_dis_all;
}
- master->num_chipselect = GQSPI_DEFAULT_NUM_CS;
+ ret = of_property_read_u32(pdev->dev.of_node, "num-cs", &num_cs);
+ if (ret < 0)
+ master->num_chipselect = GQSPI_DEFAULT_NUM_CS;
+ else
+ master->num_chipselect = num_cs;
master->setup = zynqmp_qspi_setup;
master->set_cs = zynqmp_qspi_chipselect;
--
2.10.2
[PATCH] Staging: iio: adc: fix macro and sysfs files modes in ad7280a.c
Fixes warnings found by checkpatch.pl:
- AD7280A_DEVADDR macro to use typeof, because of possible side effects
- sysfs entries user/group modes to use their octal representation
- coding style (open parenthesis alignment, CamelCase...)
Signed-off-by: Boyan Vladinov
---
drivers/staging/iio/adc/ad7280a.c | 141 +-
drivers/staging/iio/adc/ad7280a.h | 6 ++
2 files changed, 101 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7280a.c
b/drivers/staging/iio/adc/ad7280a.c
index ee679ac0368f..5f687c6aaaeb 100644
--- a/drivers/staging/iio/adc/ad7280a.c
+++ b/drivers/staging/iio/adc/ad7280a.c
@@ -99,9 +99,11 @@
#define AD7280A_DEVADDR_MASTER 0
#define AD7280A_DEVADDR_ALL0x1F
/* 5-bit device address is sent LSB first */
-#define AD7280A_DEVADDR(addr) (((addr & 0x1) << 4) | ((addr & 0x2) << 3) | \
- (addr & 0x4) | ((addr & 0x8) >> 3) | \
- ((addr & 0x10) >> 4))
+#define AD7280A_DEVADDR(addr) \
+ ({ typeof(addr) _addr = (addr); \
+ ((_addr & 0x1) << 4) | ((_addr & 0x2) << 3) | \
+ (_addr & 0x4) | ((_addr & 0x8) >> 3) | \
+ ((_addr & 0x10) >> 4); })
/* During a read a valid write is mandatory.
* So writing to the highest available address (Address 0x1F)
@@ -159,8 +161,8 @@ static unsigned char ad7280_calc_crc8(unsigned char
*crc_tab, unsigned int val)
{
unsigned char crc;
- crc = crc_tab[val >> 16 & 0xFF];
- crc = crc_tab[crc ^ (val >> 8 & 0xFF)];
+ crc = crc_tab[val >> 16 & 0xff];
+ crc = crc_tab[crc ^ (val >> 8 & 0xff)];
return crc ^ (val & 0xFF);
}
@@ -559,7 +561,7 @@ static int ad7280_attr_init(struct ad7280_state *st)
st->iio_attr[cnt].address =
AD7280A_DEVADDR(dev) << 8 | ch;
st->iio_attr[cnt].dev_attr.attr.mode =
- S_IWUSR | S_IRUGO;
+ 0644;
st->iio_attr[cnt].dev_attr.show =
ad7280_show_balance_sw;
st->iio_attr[cnt].dev_attr.store =
@@ -576,7 +578,7 @@ static int ad7280_attr_init(struct ad7280_state *st)
AD7280A_DEVADDR(dev) << 8 |
(AD7280A_CB1_TIMER + ch);
st->iio_attr[cnt].dev_attr.attr.mode =
- S_IWUSR | S_IRUGO;
+ 0644;
st->iio_attr[cnt].dev_attr.show =
ad7280_show_balance_timer;
st->iio_attr[cnt].dev_attr.store =
@@ -679,6 +681,51 @@ static ssize_t ad7280_write_channel_config(struct device
*dev,
return ret ? ret : len;
}
+static void ad7280a_push_event(struct iio_dev *indio_dev,
+ enum event_code_type event_code_t,
+ enum iio_chan_type iio_chan_t,
+ int diff,
+ int modifier,
+ enum iio_event_direction iio_event_dir,
+ enum iio_event_type iio_event_t,
+ int chan,
+ int chan1,
+ int chan2,
+ int number)
+{
+ switch (event_code_t) {
+ case AD7280A_IIO_EVENT_CODE:
+ iio_push_event(indio_dev,
+ IIO_EVENT_CODE(iio_chan_t,
+ diff,
+ modifier,
+ iio_event_dir,
+ iio_event_t,
+ chan,
+ chan1,
+ chan2),
+ iio_get_time_ns(indio_dev));
+ break;
+ case AD7280A_IIO_MOD_EVENT_CODE:
+ iio_push_event(indio_dev,
+ IIO_MOD_EVENT_CODE(iio_chan_t,
+ number,
+ modifier,
+ iio_event_t,
+ iio_event_dir),
+ iio_get_time_ns(indio_dev));
+ break;
+ case AD7280A_IIO_UNMOD_EVENT_CODE:
+ iio_push_event(indio_dev,
+ IIO_UNMOD_EVENT_CODE(iio_chan_t,
+ number,
+ iio_event_t,
+ iio_event_dir),
+ iio_get_time_ns(indio_dev));
+
Re: Linux 4.8.11
On Sun, Nov 27, 2016 at 12:35:45AM +0100, Adam Borowski wrote: > [0.332919] BUG: unable to handle kernel NULL pointer dereference at > (null) > [0.340902] IP: [< (null)>] (null) > [0.346063] PGD 0 > [0.348181] Oops: 0010 [#1] SMP > [0.351364] Modules linked in: > [0.354526] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.11+ #1 > [0.360582] Hardware name: System manufacturer System Product Name/M4A77T, > BIOS 240105/18/2011 > [0.369589] task: 88022e120bc0 task.stack: 88022e124000 > [0.375549] RIP: 0010:[<>] [< (null)>] > (null) > [0.383139] RSP: 0018:88022e127eb8 EFLAGS: 00010297 > [0.388497] RAX: 0001 RBX: RCX: > > [0.395675] RDX: 88022f002880 RSI: 0010 RDI: > 88022f0028a0 > [0.402853] RBP: 81d00e13 R08: fffe R09: > 88022f002880 > [0.410027] R10: 700117a0 R11: dc161723 R12: > 880237c16780 > [0.417204] R13: 81c0b9c0 R14: 81817cc0 R15: > 88022e120040 > [0.424382] FS: () GS:880237c0() > knlGS: > [0.432521] CS: 0010 DS: ES: CR0: 80050033 > [0.438308] CR2: CR3: 01c06000 CR4: > 06f0 > [0.445484] Stack: > [0.447544] 81000410 81c3c300 > > [0.455210] 0008 81968f9c 810690c8 > > [0.462865] a080 81d94310 0001 > 880237c16780 > [0.470544] Call Trace: > [0.475836] [] ? do_one_initcall+0x40/0x150 Booting with initcall_debug might give us some info. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: INFO: rcu_sched detected stalls on CPUs/tasks with `kswapd` and `mem_cgroup_shrink_node`
On 24.11.2016 11:15, Michal Hocko wrote:
On Mon 21-11-16 16:35:53, Donald Buczek wrote:
[...]
Hello,
thanks a lot for looking into this!
Let me add some information from the reporting site:
* We've tried the patch from Paul E. McKenney (the one posted Wed, 16 Nov
2016) and it doesn't shut up the rcu stall warnings.
* Log file from a boot with the patch applied ( grep kernel
/var/log/messages ) is here :
http://owww.molgen.mpg.de/~buczek/321322/2016-11-21_syslog.txt
* This system is a backup server and walks over thousands of files sometimes
with multiple parallel rsync processes.
* No rcu_* warnings on that machine with 4.7.2, but with 4.8.4 , 4.8.6 ,
4.8.8 and now 4.9.0-rc5+Pauls patch
I assume you haven't tried the Linus 4.8 kernel without any further
stable patches? Just to be sure we are not talking about some later
regression which found its way to the stable tree.
We've tried v4.8 and got the first rcu stall warnings with this, too.
First one after about 20 hours uptime.
* When the backups are actually happening there might be relevant memory
pressure from inode cache and the rsync processes. We saw the oom-killer
kick in on another machine with same hardware and similar (a bit higher)
workload. This other machine also shows a lot of rcu stall warnings since
4.8.4.
* We see "rcu_sched detected stalls" also on some other machines since we
switched to 4.8 but not as frequently as on the two backup servers. Usually
there's "shrink_node" and "kswapd" on the top of the stack. Often
"xfs_reclaim_inodes" variants on top of that.
I would be interested to see some reclaim tracepoints enabled. Could you
try that out? At least mm_shrink_slab_{start,end} and
mm_vmscan_lru_shrink_inactive. This should tell us more about how the
reclaim behaved.
http://owww.molgen.mpg.de/~buczek/321322/2016-11-26.dmesg.txt (80K)
http://owww.molgen.mpg.de/~buczek/321322/2016-11-26.trace.txt (50M)
Traces wrapped, but the last event is covered. all vmscan events were
enabled
--
Donald Buczek
buc...@molgen.mpg.de
Tel: +49 30 8413 1433
ALSA Audio play
Hi team, I am new to the field of linux kernel..I have heard about ALSA ..my doubt is that.. does ALSA is already there in kernel..?I am asking this question because I Have made a c program that play .wav files by ALSA which runs in my ubuntu now..I want to cross compile this to my beaglebone board.. hopping for a clarification -ComeLet's enjoy the world of Open Source --- Best regards, Jithu
Re: INFO: rcu_sched detected stalls on CPUs/tasks with `kswapd` and `mem_cgroup_shrink_node`
Am Donnerstag, den 24.11.2016, 19:50 +0100 schrieb Donald Buczek:
> On 24.11.2016 11:15, Michal Hocko wrote:
>
> > On Mon 21-11-16 16:35:53, Donald Buczek wrote:
> > [...]
> >> Let me add some information from the reporting site:
> >>
> >> * We've tried the patch from Paul E. McKenney (the one posted Wed, 16 Nov
> >> 2016) and it doesn't shut up the rcu stall warnings.
> >>
> >> * Log file from a boot with the patch applied ( grep kernel
> >> /var/log/messages ) is here :
[…]
> >> * This system is a backup server and walks over thousands of files
> >> sometimes
> >> with multiple parallel rsync processes.
> >>
> >> * No rcu_* warnings on that machine with 4.7.2, but with 4.8.4 , 4.8.6 ,
> >> 4.8.8 and now 4.9.0-rc5+Pauls patch
> > I assume you haven't tried the Linus 4.8 kernel without any further
> > stable patches? Just to be sure we are not talking about some later
> > regression which found its way to the stable tree.
We tried, and the problem also shows up with the plain 4.8 kernel.
```
$ dmesg
[…]
[77554.135657] INFO: rcu_sched detected stalls on CPUs/tasks:
[77554.135662] 1-...: (222 ticks this GP) idle=7dd/140/0
softirq=30962751/30962968 fqs=12961
[77554.135663] (detected by 10, t=60002 jiffies, g=7958132, c=7958131, q=90237)
[77554.135667] Task dump for CPU 1:
[77554.135669] kswapd1 R running task086 2 0x0008
[77554.135672] 88080ad87c58 88080ad87c58 88080ad87cf8
88100c1e5200
[77554.135674] 0003 88080ad87e60
88080ad87d90
[77554.135675] 811345f5 88080ad87da0 88080ad87db0
88100c1e5200
[77554.135677] Call Trace:
[77554.135684] [] ? shrink_node_memcg+0x605/0x870
[77554.135686] [] ? shrink_node+0xbf/0x1c0
[77554.135687] [] ? kswapd+0x342/0x6b0
[77554.135689] [] ? mem_cgroup_shrink_node+0x150/0x150
[77554.135692] [] ? kthread+0xc4/0xe0
[77554.135695] [] ? ret_from_fork+0x1f/0x40
[77554.135696] [] ? kthread_worker_fn+0x160/0x160
[77734.252362] INFO: rcu_sched detected stalls on CPUs/tasks:
[77734.252367] 1-...: (897 ticks this GP) idle=7dd/140/0
softirq=30962751/30963197 fqs=50466
[77734.252368] (detected by 0, t=240122 jiffies, g=7958132, c=7958131,
q=456322)
[77734.252372] Task dump for CPU 1:
[77734.252373] kswapd1 R running task086 2 0x0008
[77734.252376] 88080ad87c58 88080ad87c58 88080ad87cf8
88100c1e5200
[77734.252378] 0003 88080ad87e60
88080ad87d90
[77734.252380] 811345f5 88080ad87da0 88080ad87db0
88100c1e5200
[77734.252382] Call Trace:
[77734.252388] [] ? shrink_node_memcg+0x605/0x870
[77734.252390] [] ? shrink_node+0xbf/0x1c0
[77734.252391] [] ? kswapd+0x342/0x6b0
[77734.252393] [] ? mem_cgroup_shrink_node+0x150/0x150
[77734.252396] [] ? kthread+0xc4/0xe0
[77734.252399] [] ? ret_from_fork+0x1f/0x40
[77734.252401] [] ? kthread_worker_fn+0x160/0x160
[…]
```
> >> * When the backups are actually happening there might be relevant memory
> >> pressure from inode cache and the rsync processes. We saw the oom-killer
> >> kick in on another machine with same hardware and similar (a bit higher)
> >> workload. This other machine also shows a lot of rcu stall warnings since
> >> 4.8.4.
> >>
> >> * We see "rcu_sched detected stalls" also on some other machines since we
> >> switched to 4.8 but not as frequently as on the two backup servers. Usually
> >> there's "shrink_node" and "kswapd" on the top of the stack. Often
> >> "xfs_reclaim_inodes" variants on top of that.
> >
> > I would be interested to see some reclaim tracepoints enabled. Could you
> > try that out? At least mm_shrink_slab_{start,end} and
> > mm_vmscan_lru_shrink_inactive. This should tell us more about how the
> > reclaim behaved.
>
> We'll try that tomorrow!
Unfortunately, looking today at `trace`, the corresponding messages have
already been thrown out the buffer. We continue trying.
Kind regards,
Paul Menzel
Xmas Offer
You are a recipient to Mrs Julie Leach Donation of $3 million USD. Contact ( julieleac...@gmail.com ) for claims.
Re: [PATCH] Staging: iio: adc: fix macro and sysfs files modes in ad7280a.c
On 27/11/16 08:37, Boyan Vladinov wrote:
> Fixes warnings found by checkpatch.pl:
> - AD7280A_DEVADDR macro to use typeof, because of possible side effects
Such as? I can't tell from this description whether this is a bug, or just
some good coding practice stuff.
> - sysfs entries user/group modes to use their octal representation
> - coding style (open parenthesis alignment, CamelCase...)
>
> Signed-off-by: Boyan Vladinov
There are several unrelated changes here. One patch for each unrelated
change please.
Various comments inline.
The content is mostly fine. You just need to work on how it is presented
for review.
Looking forward to the updated series!
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7280a.c | 141
> +-
> drivers/staging/iio/adc/ad7280a.h | 6 ++
> 2 files changed, 101 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7280a.c
> b/drivers/staging/iio/adc/ad7280a.c
> index ee679ac0368f..5f687c6aaaeb 100644
> --- a/drivers/staging/iio/adc/ad7280a.c
> +++ b/drivers/staging/iio/adc/ad7280a.c
> @@ -99,9 +99,11 @@
> #define AD7280A_DEVADDR_MASTER 0
> #define AD7280A_DEVADDR_ALL 0x1F
> /* 5-bit device address is sent LSB first */
> -#define AD7280A_DEVADDR(addr)(((addr & 0x1) << 4) | ((addr & 0x2) <<
> 3) | \
> - (addr & 0x4) | ((addr & 0x8) >> 3) | \
> - ((addr & 0x10) >> 4))
> +#define AD7280A_DEVADDR(addr)\
> + ({ typeof(addr) _addr = (addr); \
> + ((_addr & 0x1) << 4) | ((_addr & 0x2) << 3) | \
> + (_addr & 0x4) | ((_addr & 0x8) >> 3) | \
> + ((_addr & 0x10) >> 4); })
I'd like an explanation of why this is necessary. Are we looking at an
actual bug, or is this about prevenint plausible issues if this macro is
used with a different data type for address in the future?
Also if this is an actual bug please make it the first patch in the broken
out series of patches. That way we have the option to route it to mainline
faster and it can be applied to stable kernels more easily.
>
> /* During a read a valid write is mandatory.
> * So writing to the highest available address (Address 0x1F)
> @@ -159,8 +161,8 @@ static unsigned char ad7280_calc_crc8(unsigned char
> *crc_tab, unsigned int val)
> {
> unsigned char crc;
>
> - crc = crc_tab[val >> 16 & 0xFF];
> - crc = crc_tab[crc ^ (val >> 8 & 0xFF)];
> + crc = crc_tab[val >> 16 & 0xff];
Why? This is not hurting readability. It's also not camel case if that is
what you meant by camel case in the introduction.
If it is about consistency within the driver then fine, but please state this.
As it's within this large multi part patch it's not obvious how it relates
to the description.
> + crc = crc_tab[crc ^ (val >> 8 & 0xff)];
>
> return crc ^ (val & 0xFF);
> }
> @@ -559,7 +561,7 @@ static int ad7280_attr_init(struct ad7280_state *st)
> st->iio_attr[cnt].address =
> AD7280A_DEVADDR(dev) << 8 | ch;
> st->iio_attr[cnt].dev_attr.attr.mode =
> - S_IWUSR | S_IRUGO;
> + 0644;
hmm. I must admit I'm really disliking the noise that came from a fairly
throwaway comment from Linus intended to stop people patching it the other
way.
I'll probably take these patches but most as a way to stop recieving the same
one every few days/weeks as checkpatch is now highlighting it.
> st->iio_attr[cnt].dev_attr.show =
> ad7280_show_balance_sw;
> st->iio_attr[cnt].dev_attr.store =
> @@ -576,7 +578,7 @@ static int ad7280_attr_init(struct ad7280_state *st)
> AD7280A_DEVADDR(dev) << 8 |
> (AD7280A_CB1_TIMER + ch);
> st->iio_attr[cnt].dev_attr.attr.mode =
> - S_IWUSR | S_IRUGO;
> + 0644;
> st->iio_attr[cnt].dev_attr.show =
> ad7280_show_balance_timer;
> st->iio_attr[cnt].dev_attr.store =
> @@ -679,6 +681,51 @@ static ssize_t ad7280_write_channel_config(struct device
> *dev,
> return ret ? ret : len;
> }
>
This bit of refactoring is reasonable to reduced excessive indentation, but
it should be in a patch on it's own with a description of why you are making
the change.
Actually scratch that, it's not actually making the code any clear at all
looking inline.
> +static void ad7280a_push_event(struct iio_dev *indio_dev,
> +enum event_code_type event_code_t,
> +enum iio_chan_type iio_chan_t,
> +int diff,
> +int modifier,
> +enum iio_event_direction ii
[LINUX RFC v4 1/4] spi: adding support for data stripe feature in core
This patch enables data stripe feature in spi core. This feature is
required to support dual parallel mode of ZynqMP GQSPI controller.
To achieve the same an API SPI_MASTER_DATA_STRIPE is added.
With data stripe enabled,
- even bytes i.e. 0, 2, 4,... are transmitted on lower data bus
- odd bytes i.e. 1, 3, 5,.. are transmitted on upper data bus.
To support data stripe; need to assert both chip selects once.
This is achieved through API SPI_MASTER_BOTH_CS.
Signed-off-by: Naga Sureshkumar Relli
---
Changes for v4:
- No changes, sending the previous one as is
Change for v3:
- Updated comments for newly added APIs
- Changed patch description for ease of understanding
Changes for v2:
- Added error handling condition for newly added features
---
drivers/spi/spi.c | 8
include/linux/spi/spi.h | 11 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 5787b72..01980af 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2538,6 +2538,14 @@ static int __spi_validate(struct spi_device *spi, struct
spi_message *message)
if (list_empty(&message->transfers))
return -EINVAL;
+ /*
+* Data stripe option is selected if and only if when
+* two chips are enabled
+*/
+ if ((master->flags & SPI_MASTER_DATA_STRIPE)
+ && !(master->flags & SPI_MASTER_BOTH_CS))
+ return -EINVAL;
+
/* Half-duplex links include original MicroWire, and ones with
* only one data pin like SPI_3WIRE (switches direction) or where
* either MOSI or MISO is missing. They can also be caused by
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 4b743ac..94a5e6a 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -443,6 +443,17 @@ struct spi_master {
#define SPI_MASTER_MUST_RX BIT(3) /* requires rx */
#define SPI_MASTER_MUST_TX BIT(4) /* requires tx */
+ /* Controller may support data stripe feature when more than one
+* chips are present.
+* Setting data stripe will send data in following manner:
+* -> even bytes i.e. 0, 2, 4,... are transmitted on lower data bus
+* -> odd bytes i.e. 1, 3, 5,.. are transmitted on upper data bus
+*/
+#define SPI_MASTER_DATA_STRIPE BIT(7) /* support data stripe */
+ /* Controller may support asserting more than one chip select at once.
+* This flag will enable that feature.
+*/
+#define SPI_MASTER_BOTH_CS BIT(8) /* assert both chip selects */
/*
* on some hardware transfer / message size may be constrained
* the limit may depend on device transfer settings
--
2.10.2
Re: [PATCH v3] Staging: iio: adc: fix sysfs files modes in ad7192.c
On 26/11/16 22:39, Boyan Vladinov wrote:
> Fixes warnings found by checkpatch.pl:
> - sysfs entries user/group modes to use their octal representation
> - use the IIO_DEVICE_ATTR_[RO|RW] macroses
> - coding style
>
> Signed-off-by: Boyan Vladinov
Unfortunately this isn't quite as straight forward as it initially appears.
Making these changes is good if it makes the code simpler of cleaner. In a
couple
of cases here it actually makes it harder to tell what is going on.
Anyhow, a few suggestions inline on how to proceed.
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c | 39 ---
> 1 file changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index 1fb68c01abd5..29b8a291fb6a 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -340,15 +340,21 @@ ad7192_show_scale_available(struct device *dev,
> return len;
> }
>
> +static ssize_t
> +in_voltage_scale_available_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return ad7192_show_scale_available(dev, attr, buf);
> +}
> +
> static IIO_DEVICE_ATTR_NAMED(in_v_m_v_scale_available,
>in_voltage-voltage_scale_available,
> - S_IRUGO, ad7192_show_scale_available, NULL, 0);
> + 0444, ad7192_show_scale_available, NULL, 0);
>
> -static IIO_DEVICE_ATTR(in_voltage_scale_available, S_IRUGO,
> -ad7192_show_scale_available, NULL, 0);
> +static IIO_DEVICE_ATTR_RO(in_voltage_scale_available, 0);
I'd prefer this one was left alone. By using the macro for one of the two cases
we've just obscured the fact that they are really the same thing just with two
different names.
We do have new infrastructure to support available attributes directly in the
core.
If you want to look at implementing both of these using that it would be great.
See the info_mask_*_available elements of struct iio_dev and the read_avail
callback. Documentation is a bit weak on these at the moment unfortunately so
you may want to look back at the descriptions of the patches that introduced
them.
>
> -static ssize_t ad7192_show_ac_excitation(struct device *dev,
> - struct device_attribute *attr,
> +static ssize_t ac_excitation_en_show(struct device *dev,
> + struct device_attribute *attr,
>char *buf)
> {
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> @@ -357,8 +363,8 @@ static ssize_t ad7192_show_ac_excitation(struct device
> *dev,
> return sprintf(buf, "%d\n", !!(st->mode & AD7192_MODE_ACX));
> }
>
> -static ssize_t ad7192_show_bridge_switch(struct device *dev,
> - struct device_attribute *attr,
> +static ssize_t bridge_switch_en_show(struct device *dev,
> + struct device_attribute *attr,
>char *buf)
> {
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> @@ -367,8 +373,8 @@ static ssize_t ad7192_show_bridge_switch(struct device
> *dev,
> return sprintf(buf, "%d\n", !!(st->gpocon & AD7192_GPOCON_BPDSW));
> }
>
> -static ssize_t ad7192_set(struct device *dev,
> - struct device_attribute *attr,
> +static ssize_t bridge_switch_en_store(struct device *dev,
> + struct device_attribute *attr,
> const char *buf,
> size_t len)
> {
> @@ -412,13 +418,16 @@ static ssize_t ad7192_set(struct device *dev,
> return ret ? ret : len;
> }
>
> -static IIO_DEVICE_ATTR(bridge_switch_en, S_IRUGO | S_IWUSR,
> -ad7192_show_bridge_switch, ad7192_set,
> -AD7192_REG_GPOCON);
> +static ssize_t ac_excitation_en_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
This function naming is confusing. It's not enabling the bridge switch in this
case... Hence if you were going to do this you'd need to wrap a single function
with a name covering both cases, once for each of the cases.
Or take the view that the 'shared' code is trivial and break out the relevant
bits
into each of these two functions directly.
> + return bridge_switch_en_store(dev, attr, buf, len);
> +}
> +
> +static IIO_DEVICE_ATTR_RW(bridge_switch_en, AD7192_REG_GPOCON);
>
> -static IIO_DEVICE_ATTR(ac_excitation_en, S_IRUGO | S_IWUSR,
> -ad7192_show_ac_excitation, ad7192_set,
> -AD7192_REG_MODE);
> +static IIO_DEVICE_ATTR_RW(ac_excitation_en, AD7192_REG_MODE);
>
> static struct attribute *ad7192_attributes[] = {
> &iio_dev_attr_in_v_m_v_scale_available.dev_a
Did you get my message this time?
Friedrich MayrhoferThis is the second time i am sending you this mail.I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
Re: [PATCH] iio: cros_ec_light_prox: add ChromeOS EC Light and Proximity Sensors
On 25/11/16 12:03, Enric Balletbo i Serra wrote:
> From: Gwendal Grignou
>
> Handle Light and Proximity sensors presented by the ChromeOS EC Sensor hub.
> Creates an IIO device for each functions.
>
> Signed-off-by: Gwendal Grignou
> Signed-off-by: Guenter Roeck
> Signed-off-by: Enric Balletbo i Serra
A few comments / questions inline. We've missed the upcoming merge window
now anyway so plenty of time to tidy up loose ends.
Thanks,
Jonathan
> ---
> drivers/iio/common/cros_ec_sensors/Kconfig | 8 +
> drivers/iio/common/cros_ec_sensors/Makefile| 1 +
> .../common/cros_ec_sensors/cros_ec_light_prox.c| 278
> +
> 3 files changed, 287 insertions(+)
> create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_light_prox.c
>
> diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig
> b/drivers/iio/common/cros_ec_sensors/Kconfig
> index 135f682..4fd0b87 100644
> --- a/drivers/iio/common/cros_ec_sensors/Kconfig
> +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
> @@ -20,3 +20,11 @@ config IIO_CROS_EC_SENSORS
> Accelerometers, Gyroscope and Magnetometer that are
> presented by the ChromeOS EC Sensor hub.
> Creates an IIO device for each functions.
> +
> +config IIO_CROS_EC_LIGHT_PROX
> + tristate "ChromeOS EC Light and Proximity Sensors"
> + select IIO_CROS_EC_SENSORS_CORE
As the build bot has pointed out this doesn't work...
I'd go with depends on myself as it's simpler than making sure to select
the whole tree of things needed.
> + help
> + Module to handle Light and Proximity sensors
> + presented by the ChromeOS EC Sensor hub.
> + Creates an IIO device for each functions.
> diff --git a/drivers/iio/common/cros_ec_sensors/Makefile
> b/drivers/iio/common/cros_ec_sensors/Makefile
> index ec716ff..7aaf2a2 100644
> --- a/drivers/iio/common/cros_ec_sensors/Makefile
> +++ b/drivers/iio/common/cros_ec_sensors/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_IIO_CROS_EC_SENSORS_CORE) += cros_ec_sensors_core.o
> obj-$(CONFIG_IIO_CROS_EC_SENSORS) += cros_ec_sensors.o
> +obj-$(CONFIG_IIO_CROS_EC_LIGHT_PROX) += cros_ec_light_prox.o
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_light_prox.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_light_prox.c
> new file mode 100644
> index 000..40a34de
> --- /dev/null
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_light_prox.c
> @@ -0,0 +1,278 @@
> +/*
> + * cros_ec_light_prox - Driver for light and prox sensors behing CrosEC.
> + *
> + * Copyright (C) 2016 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "cros_ec_sensors_core.h"
> +
> +/*
> + * We only represent one entry for light or proximity. EC is merging
> different
> + * light sensors to return the what the eye would see. For proximity, we
> + * currently support only one light source.
> + */
> +#define CROS_EC_LIGHT_PROX_MAX_CHANNELS (1 + 1)
> +
> +/* State data for ec_sensors iio driver. */
> +struct cros_ec_sensors_state {
> + /* Shared by all sensors */
> + struct cros_ec_sensors_core_state core;
> +
> + struct iio_chan_spec channels[CROS_EC_LIGHT_PROX_MAX_CHANNELS];
> +};
> +
> +static int cros_ec_light_prox_read(struct iio_dev *indio_dev,
> +struct iio_chan_spec const *chan,
> +int *val, int *val2, long mask)
> +{
> + struct cros_ec_sensors_state *st = iio_priv(indio_dev);
> + u16 data = 0;
> + s64 val64;
> + int ret;
> + int idx = chan->scan_index;
> +
> + mutex_lock(&st->core.cmd_lock);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + ret = cros_ec_sensors_read_cmd(indio_dev, 1 << idx,
> +(s16 *)&data);
As I read the code, this is already being output in lux or
> + if (ret < 0)
> + break;
> + *val = data;
> + break;
> + case IIO_CHAN_INFO_CALIBBIAS:
> + st->core.param.cmd = MOTIONSENSE_CMD_SENSOR_OFFSET;
> + st->core.param.sensor_offset.flags = 0;
> +
> + ret = cros_ec_motion_send_host_cmd(&st->core, 0);
> + if (ret < 0)
> + break;
> +
> + /* Save values */
> + st->core.calib[0] = st->core.resp->sensor_offset
Re: [PATCH] IIO: Change msleep to usleep_range for small msecs
On 26/11/16 03:47, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device suspend time, device enable time, data reading time, etc.
> Thus, change msleep to usleep_range for precise wakeups.
>
> Signed-off-by: Aniroop Mathur
As these need individual review by the various original authors and driver
maintainers to
establish the intent of the sleep, it would have been better to have done a
series of
patches (one per driver) with the relevant maintainers cc'd on the ones that
they care about.
Most of these are ADI parts looked after by Lars though so perhaps wait for his
comments
before respining.
> ---
> drivers/iio/adc/exynos_adc.c | 2 +-
> drivers/iio/pressure/bmp280-core.c | 14 +++---
> drivers/staging/iio/meter/ade7753.c | 2 +-
> drivers/staging/iio/meter/ade7753.h | 2 +-
> drivers/staging/iio/meter/ade7754.c | 2 +-
> drivers/staging/iio/meter/ade7754.h | 2 +-
> drivers/staging/iio/meter/ade7758.h | 2 +-
> drivers/staging/iio/meter/ade7758_core.c | 2 +-
> drivers/staging/iio/meter/ade7759.c | 2 +-
> drivers/staging/iio/meter/ade7759.h | 2 +-
> drivers/staging/iio/meter/ade7854.c | 2 +-
> drivers/staging/iio/meter/ade7854.h | 2 +-
> 12 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index c15756d..ad1775b 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -632,7 +632,7 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
> input_report_key(info->input, BTN_TOUCH, 1);
> input_sync(info->input);
>
> - msleep(1);
> + usleep_range(1000, 1100);
This needs feedback on what an appropriate range actually is. Also in this
particular
case they will have a better idea of what msleep delivers as it's on a SoC
where the clocks
are entirely under their control. Worth adding a cc for Naveen as well as the
original
driver author (may well bounce - I have no idea!)
> };
>
> writel(0, ADC_V1_CLRINTPNDNUP(info->regs));
> diff --git a/drivers/iio/pressure/bmp280-core.c
> b/drivers/iio/pressure/bmp280-core.c
> index e5a533c..4d18826 100644
> --- a/drivers/iio/pressure/bmp280-core.c
> +++ b/drivers/iio/pressure/bmp280-core.c
> @@ -65,7 +65,7 @@ struct bmp280_data {
> struct bmp180_calib calib;
> struct regulator *vddd;
> struct regulator *vdda;
> - unsigned int start_up_time; /* in milliseconds */
> + unsigned int start_up_time; /* in microseconds */
Would have been less invasive to leave this alone and just multiply by 1000
where
relevant for the sleep.
>
> /* log of base 2 of oversampling rate */
> u8 oversampling_press;
> @@ -935,14 +935,14 @@ int bmp280_common_probe(struct device *dev,
> data->chip_info = &bmp180_chip_info;
> data->oversampling_press = ilog2(8);
> data->oversampling_temp = ilog2(1);
> - data->start_up_time = 10;
> + data->start_up_time = 1;
> break;
> case BMP280_CHIP_ID:
> indio_dev->num_channels = 2;
> data->chip_info = &bmp280_chip_info;
> data->oversampling_press = ilog2(16);
> data->oversampling_temp = ilog2(2);
> - data->start_up_time = 2;
> + data->start_up_time = 2000;
> break;
> case BME280_CHIP_ID:
> indio_dev->num_channels = 3;
> @@ -950,7 +950,7 @@ int bmp280_common_probe(struct device *dev,
> data->oversampling_press = ilog2(16);
> data->oversampling_humid = ilog2(16);
> data->oversampling_temp = ilog2(2);
> - data->start_up_time = 2;
> + data->start_up_time = 2000;
> break;
> default:
> return -EINVAL;
> @@ -979,7 +979,7 @@ int bmp280_common_probe(struct device *dev,
> goto out_disable_vddd;
> }
> /* Wait to make sure we started up properly */
> - mdelay(data->start_up_time);
> + usleep_range(data->start_up_time, data->start_up_time + 100);
As this in probe I doubt we really care. Could just set it longer to shut up
the warnings.
Still would like some input from say Linus on this...
>
> /* Bring chip out of reset if there is an assigned GPIO line */
> gpiod = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> @@ -1038,7 +1038,7 @@ int bmp280_common_probe(struct device *dev,
>* Set autosuspend to two orders of magnitude larger than the
>* start-up time.
>*/
> - pm_runtime_set_autosuspend_delay(dev, data->start_up_time *100);
> + pm_runtime_set_autosuspend_delay(dev, data->start_up_time / 10);
Re: [PATCH v8 3/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature
On 24/11/16 18:05, H. Nikolaus Schaller wrote:
>
>> Am 24.11.2016 um 18:38 schrieb Jonathan Cameron
>> :
>>
>>
>>
>> On 22 November 2016 14:02:30 GMT+00:00, "H. Nikolaus Schaller"
>> wrote:
>>> The tsc2007 chip not only has a resistive touch screen controller but
>>> also an external AUX adc imput which can be used for an ambient
>>> light sensor, battery voltage monitoring or any general purpose.
>>>
>>> Additionally it can measure the chip temperature.
>>>
>>> This extension provides an iio interface for these adc channels.
>>>
>>> Since it is not wasting much resources and is very straightforward,
>>> we simply provide all other adc channels as optional iio interfaces
>>> as weel. This can be used for debugging or special applications.
>>>
>>> This patch also splits the tsc2007 driver in several source files:
>>> tsc2007.h -- constants, structs and stubs
>>> tsc2007_core.c -- functional parts of the original driver
>>> tsc2007_iio.c -- the optional iio stuff
>>>
>>> Makefile magic allows to conditionally link the iio stuff
>>> if CONFIG_IIO=y or =m in a way that it works with
>>> CONFIG_TOUCHSCREEN_TSC2007=m.
>>>
>>> Signed-off-by: H. Nikolaus Schaller
>>> Reviewed-by: Jonathan Cameron
>>> ---
>>> drivers/input/touchscreen/Makefile | 7 +
>>> drivers/input/touchscreen/tsc2007.h| 116
>>>
>>> .../touchscreen/{tsc2007.c => tsc2007_core.c} | 95 +++--
>>> drivers/input/touchscreen/tsc2007_iio.c| 150
>>> +
>>> 4 files changed, 294 insertions(+), 74 deletions(-)
>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>>
>>> diff --git a/drivers/input/touchscreen/Makefile
>>> b/drivers/input/touchscreen/Makefile
>>> index 81b8645..3be0d19 100644
>>> --- a/drivers/input/touchscreen/Makefile
>>> +++ b/drivers/input/touchscreen/Makefile
>>> @@ -80,6 +80,13 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO) += tsc40.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2004) += tsc2004.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o
>>> +tsc2007-y := tsc2007_core.o
>>> +ifeq ($(CONFIG_IIO),y)
>>> +tsc2007-y += tsc2007_iio.o
>>> +endif
>>> +ifeq ($(CONFIG_IIO),m)
>>> +tsc2007-y += tsc2007_iio.o
>>
>> Not tsc2007-m ?
>>
>> I don't follow how this works!
>
> I guess tsc2007-y is an internal collector variable name
> for multiple .o components. Sort of a "library" object.
>
> While
>
> obj-y += tsc2007.o adds it to the kernel
> obj-m += tsc2007.o adds it to the modules
>
> I am not sure if my explanation is correct but it appears
> to work that way.
>
> Anyways what shall we do? If CONFIG_TOUCHSCREEN_TSC2007=y
> and IIO=m we have a problem that we need dynamic binding.
Yes, we just need to block that particular combination. Only build in the IIO
support
if it is also built in. That's way I thought we'd want to add it tsc2007-m
which would
only be used if tsc2007 as a whole was built as a module.
Otherwise it would be ignored (I think!)
I'm not seeing this structure anywhere else in kernel - hence cc'd Yann and the
Kbuild list
to see if they can offer some advices.
As a quick summary, we are looking to add IIO support to this driver in the
following circumstances.
IIO and this driver are modules. (ideally handling the dependencies nicely)
IIO and this driver are both built in.
Problem case is driver built in and IIO as a module.
Jonathan
>
>>> +endif
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o
>>> obj-$(CONFIG_TOUCHSCREEN_UCB1400) += ucb1400_ts.o
>>> obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001) += wacom_w8001.o
>>> diff --git a/drivers/input/touchscreen/tsc2007.h
>>> b/drivers/input/touchscreen/tsc2007.h
>>> new file mode 100644
>>> index 000..c25932f
>>> --- /dev/null
>>> +++ b/drivers/input/touchscreen/tsc2007.h
>>> @@ -0,0 +1,116 @@
>>> +/*
>>> + * Copyright (c) 2008 MtekVision Co., Ltd.
>>> + * Kwangwoo Lee
>>> + *
>>> + * Using code from:
>>> + * - ads7846.c
>>> + * Copyright (c) 2005 David Brownell
>>> + * Copyright (c) 2006 Nokia Corporation
>>> + * - corgi_ts.c
>>> + * Copyright (C) 2004-2005 Richard Purdie
>>> + * - omap_ts.[hc], ads7846.h, ts_osk.c
>>> + * Copyright (C) 2002 MontaVista Software
>>> + * Copyright (C) 2004 Texas Instruments
>>> + * Copyright (C) 2005 Dirk Behme
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include
>>> +
>>> +#define TSC2007_MEASURE_TEMP0 (0x0 << 4)
>>> +#define TSC2007_MEASURE_AUX(0x2 << 4)
>>> +#define TSC2007_MEASURE_TEMP1 (0x4 << 4)
>>> +#define TSC2007
Re: Linux 4.8.11
On 2016-11-27 00:35 +0100, Adam Borowski wrote: > On Sat, Nov 26, 2016 at 05:12:35PM +0100, Greg KH wrote: >> I'm announcing the release of the 4.8.11 kernel. > > ... which splats during early boot where 4.8.10 worked fine. > > [ 0.00] Linux version 4.8.11+ (kilobyte@umbar) (gcc version 6.2.1 > 20161124 (Debian 6.2.1-5) ) #1 SMP Sat Nov 26 22:32:52 CET 2016 > [ 0.00] Command line: BOOT_IMAGE=/sys/boot/vmlinuz-4.8.11+ > root=UUID=b7c38da9-ae84-4083-a1f8-6d7b4fc33961 ro rootflags=subvol=sys > syscall.x32=y syscall.x32=y console=tty1 console=ttyS0,115200,n81 > [0.00] x86/fpu: Legacy x87 FPU detected. > [0.00] x86/fpu: Using 'eager' FPU context switches. > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009ebff] usable > [0.00] BIOS-e820: [mem 0x0009ec00-0x0009] reserved > [0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved > [0.00] BIOS-e820: [mem 0x0010-0xc7e7] usable > [0.00] BIOS-e820: [mem 0xc7e8-0xc7e97fff] ACPI > data > [0.00] BIOS-e820: [mem 0xc7e98000-0xc7ec] ACPI NVS > [0.00] BIOS-e820: [mem 0xc7ed-0xc7ef] reserved > [0.00] BIOS-e820: [mem 0xff70-0x] reserved > [0.00] BIOS-e820: [mem 0x0001-0x000237ff] usable > [0.00] NX (Execute Disable) protection: active > [0.00] SMBIOS 2.5 present. > [0.00] AGP: No AGP bridge found > [0.00] e820: last_pfn = 0x238000 max_arch_pfn = 0x4 > [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT > [0.00] e820: last_pfn = 0xc7e80 max_arch_pfn = 0x4 > [0.00] Using GB pages for direct mapping > [0.00] RAMDISK: [mem 0x3668d000-0x3733dfff] > [0.00] ACPI: Early table checksum verification disabled > [0.00] ACPI: RSDP 0x000FB510 24 (v02 ACPIAM) > [0.00] ACPI: XSDT 0xC7E80100 5C (v01 051811 XSDT1038 > 20110518 MSFT 0097) > [0.00] ACPI: FACP 0xC7E80290 F4 (v03 051811 FACP1038 > 20110518 MSFT 0097) > [ 0.00] ACPI BIOS Warning (bug): Optional FADT field > Pm2ControlBlock has valid Length but zero Address: > 0x/0x1 (20160422/tbfadt-658) > [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in > FADT/Gpe0Block: 64/32 (20160422/tbfadt-624) > [0.00] ACPI: DSDT 0xC7E80450 00DB3A (v01 A1540 A1540001 > 0001 INTL 20060113) > [0.00] ACPI: FACS 0xC7E98000 40 > [0.00] ACPI: FACS 0xC7E98000 40 > [0.00] ACPI: APIC 0xC7E80390 7C (v01 051811 APIC1038 > 20110518 MSFT 0097) > [0.00] ACPI: MCFG 0xC7E80410 3C (v01 051811 OEMMCFG > 20110518 MSFT 0097) > [0.00] ACPI: OEMB 0xC7E98040 72 (v01 051811 OEMB1038 > 20110518 MSFT 0097) > [0.00] ACPI: SRAT 0xC7E8F650 000108 (v01 AMDFAM_F_10 > 0002 AMD 0001) > [0.00] ACPI: HPET 0xC7E8F760 38 (v01 051811 OEMHPET > 20110518 MSFT 0097) > [0.00] ACPI: SSDT 0xC7E8F7A0 000DA4 (v01 A M I POWERNOW > 0001 AMD 0001) > [0.00] SRAT: PXM 0 -> APIC 0x00 -> Node 0 > [0.00] SRAT: PXM 0 -> APIC 0x01 -> Node 0 > [0.00] SRAT: PXM 0 -> APIC 0x02 -> Node 0 > [0.00] SRAT: PXM 0 -> APIC 0x03 -> Node 0 > [0.00] SRAT: PXM 0 -> APIC 0x04 -> Node 0 > [0.00] SRAT: PXM 0 -> APIC 0x05 -> Node 0 > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0xc7ff] > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x1-0x237ff] > [0.00] NUMA: Node 0 [mem 0x-0x0009] + [mem > 0x0010-0xc7ff] -> [mem 0x-0xc7ff] > [0.00] NUMA: Node 0 [mem 0x-0xc7ff] + [mem > 0x1-0x237ff] -> [mem 0x-0x237ff] > [0.00] NODE_DATA(0) allocated [mem 0x237ffa000-0x237ffdfff] > [0.00] Zone ranges: > [0.00] DMA [mem 0x1000-0x00ff] > [0.00] DMA32[mem 0x0100-0x] > [0.00] Normal [mem 0x0001-0x000237ff] > [0.00] Movable zone start for each node > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x1000-0x0009dfff] > [0.00] node 0: [mem 0x0010-0xc7e7] > [0.00] node 0: [mem 0x0001-0x000237ff] > [0.00] Initmem setup node 0 [mem > 0x1000-0x000237ff] > [0.00] ACPI: PM-Timer IO Port: 0x808 > [0.00] IOAPIC[0]: apic_id 6, version 33, address 0xfec0, GSI 0-23 > [0.00] ACPI: INT_SRC
Re: drivers/staging/greybus/bootrom.c:298:35-39: ERROR: fw is NULL but dereferenced.
On Sun, Nov 27, 2016 at 07:11:46AM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: a0d60e62ea5c88a9823410e9d0929a513e29dea2 > commit: f44dd184634d401f5cf88a6d8b4a60d5ff4f417f Merge greybus driver tree > into 4.8-rc6 > date: 10 weeks ago This is a false-positive, sorry. greg k-h > > > coccinelle warnings: (new ones prefixed by >>) > > >> drivers/staging/greybus/bootrom.c:298:35-39: ERROR: fw is NULL but > >> dereferenced. > > vim +298 drivers/staging/greybus/bootrom.c > > 90f1b617 drivers/staging/greybus/firmware.c Viresh Kumar 2015-08-12 282 > dev_err(dev, "%s: error allocating response\n", __func__); > a956d939 drivers/staging/greybus/bootrom.c Viresh Kumar 2016-05-09 283 > ret = -ENOMEM; > a956d939 drivers/staging/greybus/bootrom.c Viresh Kumar 2016-05-09 284 > goto unlock; > 90f1b617 drivers/staging/greybus/firmware.c Viresh Kumar 2015-08-12 285 > } > 90f1b617 drivers/staging/greybus/firmware.c Viresh Kumar 2015-08-12 286 > 90f1b617 drivers/staging/greybus/firmware.c Viresh Kumar 2015-08-12 287 > firmware_response = op->response->payload; > 98645a9c drivers/staging/greybus/firmware.c Johan Hovold 2015-11-19 288 > memcpy(firmware_response->data, fw->data + offset, size); > 90f1b617 drivers/staging/greybus/firmware.c Viresh Kumar 2015-08-12 289 > fc41c2da drivers/staging/greybus/firmware.c Eli Sennesh 2016-01-08 290 > dev_dbg(dev, "responding with firmware (offs = %u, size = %u)\n", offset, > fc41c2da drivers/staging/greybus/firmware.c Eli Sennesh 2016-01-08 291 > size); > fc41c2da drivers/staging/greybus/firmware.c Eli Sennesh 2016-01-08 292 > a956d939 drivers/staging/greybus/bootrom.c Viresh Kumar 2016-05-09 293 > unlock: > a956d939 drivers/staging/greybus/bootrom.c Viresh Kumar 2016-05-09 294 > mutex_unlock(&bootrom->mutex); > a956d939 drivers/staging/greybus/bootrom.c Viresh Kumar 2016-05-09 295 > a956d939 drivers/staging/greybus/bootrom.c Viresh Kumar 2016-05-09 296 > queue_work: > a956d939 drivers/staging/greybus/bootrom.c Viresh Kumar 2016-05-09 297 > /* Refresh timeout */ > a4293e1d drivers/staging/greybus/bootrom.c Viresh Kumar 2016-06-22 @298 > if (!ret && (offset + size == fw->size)) > a4293e1d drivers/staging/greybus/bootrom.c Viresh Kumar 2016-06-22 299 > next_request = NEXT_REQ_READY_TO_BOOT; > a4293e1d drivers/staging/greybus/bootrom.c Viresh Kumar 2016-06-22 300 > else > a4293e1d drivers/staging/greybus/bootrom.c Viresh Kumar 2016-06-22 301 > next_request = NEXT_REQ_GET_FIRMWARE; > a4293e1d drivers/staging/greybus/bootrom.c Viresh Kumar 2016-06-22 302 > dbb8cfeb drivers/staging/greybus/bootrom.c Viresh Kumar 2016-06-22 303 > gb_bootrom_set_timeout(bootrom, next_request, NEXT_REQ_TIMEOUT_MS); > a956d939 drivers/staging/greybus/bootrom.c Viresh Kumar 2016-05-09 304 > a956d939 drivers/staging/greybus/bootrom.c Viresh Kumar 2016-05-09 305 > return ret; > 90f1b617 drivers/staging/greybus/firmware.c Viresh Kumar 2015-08-12 306 } > > :: The code at line 298 was first introduced by commit > :: a4293e1d4e6416477976ee3bd248589d3fc4bb19 greybus: bootrom: Enhance > timeout error message > > :: TO: Viresh Kumar > :: CC: Greg Kroah-Hartman > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH 3/3] iio: st_pressure: Support i2c probe using acpi
On 24/11/16 14:28, Linus Walleij wrote:
> On Thu, Nov 24, 2016 at 6:33 AM, Shrirang Bagul
> wrote:
>
>> Compatible strings are not available on ACPI based systems. This patch adds
>> support to use DSDT information read from platform BIOS instead for probing
>> st pressure sensors.
>>
>> Signed-off-by: Shrirang Bagul
> (...)
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id st_press_acpi_match[] = {
>> + {"SNO9210", LPS22HB},
>> + { },
>> +};
>
> Same comment. One sensor only supported by ACPI really?
As demonstrated by this one, they are often registered under effectively random
names!
Digging out those random names and associating them with a particular chip is
always
going to be a non trivial job.
Hence I'm happy to take these as they stand. We can add more entries when we
come
across them.
>
> Take a wider look.
Shirang has done a good job identifying this one and sending it upstream.
Be nice Linus and don't try to get him to do all the hard work ;)
As such applied to the togreg branch of iio.git. Will be pushed out as testing
for
the autobuilders to play with it.
Note there will be some weeks before I push this out as togreg (given merge
window
is about to open) so plenty of time for others to take a look!
Thanks,
Jonathan
>
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH 2/3] iio: st_accel: Support sensor i2c probe using acpi
On 24/11/16 14:26, Linus Walleij wrote:
> On Thu, Nov 24, 2016 at 6:33 AM, Shrirang Bagul
> wrote:
>
>> Add support to probe st_accel sensors on i2c bus using ACPI. Compatible
>> strings are not avaialable on ACPI based systems.
>>
>> Signed-off-by: Shrirang Bagul
> (...)
>
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id st_accel_acpi_match[] = {
>> + {"SMO8A90", LNG2DM},
>> + { },
>> +};
>
> Why is ACPI only supporting one out of 14 devices?
>
> Surely there are some out-of-tree ACPI platforms using one
> or more of the others?
>
> Apart from that it looks nice.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Anyone know where the ACPI names come from? Is there some big
list somewhere to prevent clashes?
Jonathan
>
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH v3] iio: adc: New driver for TI ADS7950 chips
On 22/11/16 00:40, David Lechner wrote:
> This adds a new driver for the TI ADS7950 family of ADC chips. These
> communicate using SPI and come in 8/10/12-bit and 4/8/12/16 channel
> varieties.
>
> Signed-off-by: David Lechner
I raised a few late comments in reponse to V2. Please address those.
Otherwise looks good to me.
Unfortunately we have just missed the upcoming merge window so we have
plenty of time to get this driver polished up for the next one!
Jonathan
> ---
>
> v3 changes:
>
> * Use spi_async() instead of spi_sync() in ti_ads7950_trigger_handler()
> * Fix scaling in ti_ads7950_read_raw()
>
> v2 changes:
>
> * Got rid of XX wildcards - using ADS7950 everywhere
> * Fixed some macro parentheses issues
> * Added TI_ prefix to macros to match ti_ prefixes used elsewhere
> * Added space in rx_buf for holding timestamp
> * Use iio_device_claim_direct_mode() and spi_message_init_with_transfers()
> helper functions
> * Don't use dev_info() at end of probe
> * Minor spelling and code style fixes
>
>
> drivers/iio/adc/Kconfig | 13 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ti-ads7950.c | 501
> +++
> 3 files changed, 515 insertions(+)
> create mode 100644 drivers/iio/adc/ti-ads7950.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 6bbee0b..26b32f0 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -527,6 +527,19 @@ config TI_ADS1015
> This driver can also be built as a module. If so, the module will be
> called ti-ads1015.
>
> +config TI_ADS7950
> + tristate "Texas Instruments ADS7950 ADC driver"
> + depends on SPI
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + Say yes here to build support for Texas Instruments ADS7950, ADS7951,
> + ADS7952, ADS7953, ADS7954, ADS7955, ADS7956, ADS7957, ADS7958,
> ADS7959.
> + ADS7960, ADS7961.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ti-ads7950.
> +
> config TI_ADS8688
> tristate "Texas Instruments ADS8688"
> depends on SPI && OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 9391217..1966801 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -49,6 +49,7 @@ obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
> obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> obj-$(CONFIG_TI_ADC161S626) += ti-adc161s626.o
> obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
> +obj-$(CONFIG_TI_ADS7950) += ti-ads7950.o
> obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
> obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
> new file mode 100644
> index 000..38b885d
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads7950.c
> @@ -0,0 +1,501 @@
> +/*
> + * Texas Instruments ADS7950 SPI ADC driver
> + *
> + * Copyright 2016 David Lechner
> + *
> + * Based on iio/ad7923.c:
> + * Copyright 2011 Analog Devices Inc
> + * Copyright 2012 CS Systemes d'Information
> + *
> + * And also on hwmon/ads79xx.c
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + * Nishanth Menon
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define TI_ADS7950_CR_MANUAL BIT(12)
> +#define TI_ADS7950_CR_WRITE BIT(11)
> +#define TI_ADS7950_CR_CHAN(ch) ((ch) << 7)
> +#define TI_ADS7950_CR_RANGE_5V BIT(6)
> +
> +#define TI_ADS7950_MAX_CHAN 16
> +
> +#define TI_ADS7950_TIMESTAMP_SIZE (sizeof(int64_t) / sizeof(__be16))
> +
> +/* val = value, dec = left shift, bits = number of bits of the mask */
> +#define TI_ADS7950_EXTRACT(val, dec, bits) \
> + (((val) >> (dec)) & ((1 << (bits)) - 1))
> +
> +struct ti_ads7950_state {
> + struct spi_device *spi;
> + struct spi_transfer ring_xfer[TI_ADS7950_MAX_CHAN + 2];
> + struct spi_transfer scan_single_xfer[3];
> + struct spi_message ring_msg;
> + struct spi_message scan_single_msg;
> +
> + struct regulator*reg;
> +
> + unsigned intsettings;
> +
> + /*
> + * DMA (thus cache coherency maintenance) requires the
> + * transfer buffers to live in their own cache lines.
> + */
> + __be16 rx_buf[TI_ADS7950_MAX_
Re: [PATCH 1/3] iio: st_sensors: match sensors using ACPI handle
On 24/11/16 05:33, Shrirang Bagul wrote:
> Add support to match st sensors using information passed from ACPI DST
> tables.
>
> Signed-off-by: Shrirang Bagul
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders
to play with it.
Presumably at somepoint this will need extending to cover the spi parts, but we
can do that when it is relevant.
Thanks,
Jonathan
> ---
> drivers/iio/common/st_sensors/st_sensors_i2c.c | 20
> include/linux/iio/common/st_sensors_i2c.h | 9 +
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_i2c.c
> b/drivers/iio/common/st_sensors/st_sensors_i2c.c
> index b43aa36..c83df4d 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_i2c.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_i2c.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -107,6 +108,25 @@ void st_sensors_of_i2c_probe(struct i2c_client *client,
> EXPORT_SYMBOL(st_sensors_of_i2c_probe);
> #endif
>
> +#ifdef CONFIG_ACPI
> +int st_sensors_match_acpi_device(struct device *dev)
> +{
> + const struct acpi_device_id *acpi_id;
> + kernel_ulong_t driver_data = 0;
> +
> + if (ACPI_HANDLE(dev)) {
> + acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
> + if (!acpi_id) {
> + dev_err(dev, "No driver data\n");
> + return -EINVAL;
> + }
> + driver_data = acpi_id->driver_data;
> + }
> + return driver_data;
> +}
> +EXPORT_SYMBOL(st_sensors_match_acpi_device);
> +#endif
> +
> MODULE_AUTHOR("Denis Ciocca ");
> MODULE_DESCRIPTION("STMicroelectronics ST-sensors i2c driver");
> MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/iio/common/st_sensors_i2c.h
> b/include/linux/iio/common/st_sensors_i2c.h
> index 1796af0..254de3c 100644
> --- a/include/linux/iio/common/st_sensors_i2c.h
> +++ b/include/linux/iio/common/st_sensors_i2c.h
> @@ -28,4 +28,13 @@ static inline void st_sensors_of_i2c_probe(struct
> i2c_client *client,
> }
> #endif
>
> +#ifdef CONFIG_ACPI
> +int st_sensors_match_acpi_device(struct device *dev);
> +#else
> +static inline int st_sensors_match_acpi_device(struct device *dev)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> #endif /* ST_SENSORS_I2C_H */
>
Re: [PATCH] iio: accel: mma8452: define unsigned return values where appropriate
On 21/11/16 19:53, Martin Kepplinger wrote:
> smatch warned:
> sval_binop_signed: invalid divide LLONG_MIN/-1
>
> and this fixes it. It's actually good to have, in order to avoid accidental
> checking for negative return values here.
>
> Signed-off-by: Martin Kepplinger
I'm assuming the nasty case doesn't actually occur so applied to the togreg
branch of iio.git
and pushed out as testing for the autobuilders to play with it.
thanks,
Jonathan
> ---
> drivers/iio/accel/mma8452.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 0e865a1..fba146f 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -248,7 +248,7 @@ static int mma8452_get_int_plus_micros_index(const int
> (*vals)[2], int n,
> return -EINVAL;
> }
>
> -static int mma8452_get_odr_index(struct mma8452_data *data)
> +static unsigned int mma8452_get_odr_index(struct mma8452_data *data)
> {
> return (data->ctrl_reg1 & MMA8452_CTRL_DR_MASK) >>
> MMA8452_CTRL_DR_SHIFT;
> @@ -260,7 +260,7 @@ static const int mma8452_samp_freq[8][2] = {
> };
>
> /* Datasheet table: step time "Relationship with the ODR" (sample frequency)
> */
> -static const int mma8452_transient_time_step_us[4][8] = {
> +static const unsigned int mma8452_transient_time_step_us[4][8] = {
> { 1250, 2500, 5000, 1, 2, 2, 2, 2 }, /* normal */
> { 1250, 2500, 5000, 1, 2, 8, 8, 8 }, /* l p l n */
> { 1250, 2500, 2500, 2500, 2500, 2500, 2500, 2500 }, /* high res*/
>
Re: [PATCH] iio: humidity: Support acpi probe for hts211
On 24/11/16 09:07, Shrirang Bagul wrote:
> Support driver probe by reading unique HID on systems based on ACPI instead
> of DT compatible strings.
>
> Signed-off-by: Shrirang Bagul
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders
to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/humidity/hts221_i2c.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/humidity/hts221_i2c.c
> b/drivers/iio/humidity/hts221_i2c.c
> index 367ecd5..8333c02 100644
> --- a/drivers/iio/humidity/hts221_i2c.c
> +++ b/drivers/iio/humidity/hts221_i2c.c
> @@ -10,6 +10,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include "hts221.h"
> @@ -83,6 +84,12 @@ static int hts221_i2c_probe(struct i2c_client *client,
> return hts221_probe(iio_dev);
> }
>
> +static const struct acpi_device_id hts221_acpi_match[] = {
> + {"SMO9100", 0},
> + { },
> +};
> +MODULE_DEVICE_TABLE(acpi, hts221_acpi_match);
> +
> static const struct of_device_id hts221_i2c_of_match[] = {
> { .compatible = "st,hts221", },
> {},
> @@ -99,6 +106,7 @@ static struct i2c_driver hts221_driver = {
> .driver = {
> .name = "hts221_i2c",
> .of_match_table = of_match_ptr(hts221_i2c_of_match),
> + .acpi_match_table = ACPI_PTR(hts221_acpi_match),
> },
> .probe = hts221_i2c_probe,
> .id_table = hts221_i2c_id_table,
>
Re: [PATCH 1/2] iio: adis1620x: Fix mixed up device descriptions
On 22/11/16 00:40, Reto Schneider wrote:
> From: Reto Schneider
> Date: Sun, 20 Nov 2016 22:11:24 +0100
> Subject: [PATCH 1/2] iio: adis1620x: Fix mixed up device descriptions
>
> The module descriptions for the ADIS 16201, 16203 and 16209 drivers do not
> match the actual function of the devices. Update them accordingly to fix
> this.
>
> Signed-off-by: Reto Schneider
Applied to the togreg branch of iio.git. Initially pushed out as testing where
it'll
be ignored by the autobuilders ;)
Jonathan
> ---
> drivers/staging/iio/accel/adis16201_core.c | 4 ++--
> drivers/staging/iio/accel/adis16203_core.c | 4 ++--
> drivers/staging/iio/accel/adis16209_core.c | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/iio/accel/adis16201_core.c
> b/drivers/staging/iio/accel/adis16201_core.c
> index 6f3f8ff..7963d4a 100644
> --- a/drivers/staging/iio/accel/adis16201_core.c
> +++ b/drivers/staging/iio/accel/adis16201_core.c
> @@ -1,5 +1,5 @@
> /*
> - * ADIS16201 Programmable Digital Vibration Sensor driver
> + * ADIS16201 Dual-Axis Digital Inclinometer and Accelerometer
> *
> * Copyright 2010 Analog Devices Inc.
> *
> @@ -243,6 +243,6 @@ static struct spi_driver adis16201_driver = {
> module_spi_driver(adis16201_driver);
>
> MODULE_AUTHOR("Barry Song <21cn...@gmail.com>");
> -MODULE_DESCRIPTION("Analog Devices ADIS16201 Programmable Digital Vibration
> Sensor driver");
> +MODULE_DESCRIPTION("Analog Devices ADIS16201 Dual-Axis Digital Inclinometer
> and Accelerometer");
> MODULE_LICENSE("GPL v2");
> MODULE_ALIAS("spi:adis16201");
> diff --git a/drivers/staging/iio/accel/adis16203_core.c
> b/drivers/staging/iio/accel/adis16203_core.c
> index c706717..f32c900 100644
> --- a/drivers/staging/iio/accel/adis16203_core.c
> +++ b/drivers/staging/iio/accel/adis16203_core.c
> @@ -1,5 +1,5 @@
> /*
> - * ADIS16203 Programmable Digital Vibration Sensor driver
> + * ADIS16203 Programmable 360 Degrees Inclinometer
> *
> * Copyright 2030 Analog Devices Inc.
> *
> @@ -211,6 +211,6 @@ static struct spi_driver adis16203_driver = {
> module_spi_driver(adis16203_driver);
>
> MODULE_AUTHOR("Barry Song <21cn...@gmail.com>");
> -MODULE_DESCRIPTION("Analog Devices ADIS16203 Programmable Digital Vibration
> Sensor driver");
> +MODULE_DESCRIPTION("Analog Devices ADIS16203 Programmable 360 Degrees
> Inclinometer");
> MODULE_LICENSE("GPL v2");
> MODULE_ALIAS("spi:adis16203");
> diff --git a/drivers/staging/iio/accel/adis16209_core.c
> b/drivers/staging/iio/accel/adis16209_core.c
> index 8dbad58..a599e19 100644
> --- a/drivers/staging/iio/accel/adis16209_core.c
> +++ b/drivers/staging/iio/accel/adis16209_core.c
> @@ -1,5 +1,5 @@
> /*
> - * ADIS16209 Programmable Digital Vibration Sensor driver
> + * ADIS16209 Dual-Axis Digital Inclinometer and Accelerometer
> *
> * Copyright 2010 Analog Devices Inc.
> *
> @@ -243,6 +243,6 @@ static struct spi_driver adis16209_driver = {
> module_spi_driver(adis16209_driver);
>
> MODULE_AUTHOR("Barry Song <21cn...@gmail.com>");
> -MODULE_DESCRIPTION("Analog Devices ADIS16209 Digital Vibration Sensor
> driver");
> +MODULE_DESCRIPTION("Analog Devices ADIS16209 Dual-Axis Digital Inclinometer
> and Accelerometer");
> MODULE_LICENSE("GPL v2");
> MODULE_ALIAS("spi:adis16209");
>
Re: [PATCH 2/2] iio: adis16203: Fix copyright year
On 22/11/16 00:42, Reto Schneider wrote: > From: Reto Schneider > Date: Mon, 12 Oct 2015 01:44:51 +0200 > Subject: [PATCH 2/2] iio: adis16203: Fix copyright year > > The copyright year can not be in the future. > > Signed-off-by: Reto Schneider Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with them. Thanks, Jonathan > --- > drivers/staging/iio/accel/adis16203_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/iio/accel/adis16203_core.c > b/drivers/staging/iio/accel/adis16203_core.c > index f32c900..bd8119a 100644 > --- a/drivers/staging/iio/accel/adis16203_core.c > +++ b/drivers/staging/iio/accel/adis16203_core.c > @@ -1,7 +1,7 @@ > /* > * ADIS16203 Programmable 360 Degrees Inclinometer > * > - * Copyright 2030 Analog Devices Inc. > + * Copyright 2010 Analog Devices Inc. > * > * Licensed under the GPL-2 or later. > */ >
[PATCH] vfio/pci: Support error recovery
It is user space driver's or device-specific driver's(in guest) responsbility
to do a serious recovery when error happened. Link-reset is one part of
recovery, when pci device is assigned to VM via vfio, link-reset will do
twice in host & guest separately, which will cause many trouble for a
successful recovery, so, disable the vfio-pci's link-reset in aer driver
in host, this is a keypoint for guest to do error recovery successfully.
CC: alex.william...@redhat.com
CC: m...@redhat.com
Signed-off-by: Cao jin
---
This is actually a RFC version(has debug lines left), and has minor changes in
aer driver, so I think maybe it is better not to CC pci guys in this round.
Later will do.
drivers/pci/pcie/aer/aerdrv_core.c | 12 ++-
drivers/vfio/pci/vfio_pci.c | 63 +++--
drivers/vfio/pci/vfio_pci_private.h | 2 ++
3 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 521e39c..289fb8e 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -496,7 +496,17 @@ static void do_recovery(struct pci_dev *dev, int severity)
"error_detected",
report_error_detected);
- if (severity == AER_FATAL) {
+ /* vfio-pci as a general meta driver, it actually couldn't do any real
+* recovery for device. It is user space driver, or device-specific
+* driver in guest who should take care of the serious error recovery,
+* link reset actually is one part of whole recovery. Doing reset_link
+* in aer driver of host kernel for vfio-pci devices will cause many
+* trouble for user space driver or guest's device-specific driver,
+* for example: the serious recovery often need to read register in
+* config space, but if register reading happens during link-resetting,
+* it is quite possible to return invalid value like all F's, which
+* will result in unpredictable error. */
+ if (severity == AER_FATAL && strcmp(dev->driver->name, "vfio-pci")) {
result = reset_link(dev);
if (result != PCI_ERS_RESULT_RECOVERED)
goto failed;
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 712a849..aefd751 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -535,6 +535,15 @@ static long vfio_pci_ioctl(void *device_data,
struct vfio_pci_device *vdev = device_data;
unsigned long minsz;
+ if (vdev->aer_recovering && (cmd == VFIO_DEVICE_SET_IRQS ||
+ cmd == VFIO_DEVICE_RESET || cmd == VFIO_DEVICE_PCI_HOT_RESET)) {
+ int ret;
+ ret = wait_for_completion_interruptible(
+ &vdev->aer_error_completion);
+ if (ret)
+ return ret;
+ }
+
if (cmd == VFIO_DEVICE_GET_INFO) {
struct vfio_device_info info;
@@ -1117,6 +1126,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
vdev->irq_type = VFIO_PCI_NUM_IRQS;
mutex_init(&vdev->igate);
spin_lock_init(&vdev->irqlock);
+ init_completion(&vdev->aer_error_completion);
ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
if (ret) {
@@ -1176,6 +1186,9 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct
pci_dev *pdev,
{
struct vfio_pci_device *vdev;
struct vfio_device *device;
+ u32 uncor_status = 0;
+ unsigned int aer_cap_offset = 0;
+ int ret;
device = vfio_device_get_from_dev(&pdev->dev);
if (device == NULL)
@@ -1187,10 +1200,30 @@ static pci_ers_result_t
vfio_pci_aer_err_detected(struct pci_dev *pdev,
return PCI_ERS_RESULT_DISCONNECT;
}
+ /* get device's uncorrectable error status as soon as possible,
+* and signal it to user space. The later we read it, the possibility
+* the register value is mangled grows. */
+ aer_cap_offset = pci_find_ext_capability(vdev->pdev,
PCI_EXT_CAP_ID_ERR);
+ ret = pci_read_config_dword(vdev->pdev, aer_cap_offset +
+PCI_ERR_UNCOR_STATUS, &uncor_status);
+if (ret)
+return PCI_ERS_RESULT_DISCONNECT;
+
+ pr_err("device %d got AER detect notification. uncorrectable error
status = 0x%x\n", pdev->devfn, uncor_status);//to be removed
mutex_lock(&vdev->igate);
+
+ vdev->aer_recovering = true;
+ reinit_completion(&vdev->aer_error_completion);
+
+ /* suspend config space access from user space,
+* when vfio-pci's error recovery process is on */
+ pci_cfg_access_trylock(vdev->pdev);
- if (vdev->err_trigger)
- eventfd_signal(vdev->err_trigger, 1);
+ if (vdev->err_trigger && uncor_status) {
+ pr_e
Re: [RFC PATCH v2 5/7] iio: multiplexer: new iio category and iio-mux driver
On 19/11/16 22:08, Peter Rosin wrote: > On 2016-11-19 16:49, Jonathan Cameron wrote: >> On 17/11/16 21:48, Peter Rosin wrote: >>> When a multiplexer changes how an iio device behaves (for example >>> by feeding different signals to an ADC), this driver can be used >>> create one virtual iio channel for each multiplexer state. >>> >>> Depends on the generic multiplexer driver. >> I'm not really following what all the ext info stuff in here is about. >> Could you add a little more description of that? > > Certainly. I have two needs for this series. The first one is simple > when it comes to the iio part and complex because the mux is shared > between three 8-way muxes on three of the inputs to an ADS-1015 ADC. > The forth ADC line to the ADS-1015 is not muxed. Those three muxes > are of course GPIO-controlled and share GPIO pins. And the GPIO > pins also control an i2c bus that is muxed 8-ways as well. There are > eight (possible) batteries, and we monitor voltage/current/temp with > the 3 muxed ADC lines, and 8 chargers sit on i2c behind the i2c mux. > I guess it felt natural for the HW designer to select battery with > the GPIO lines, but that do not fit too well with the code as it > is without this series... > > For this first need, the iio mux does not need ext_info. > > The second need is simple in the mux part but worse in the iio > department. It's another 8-way mux that simply muxes an ADC line, > so that is simple. However, the ADC line is the envelope detector > that just got added to linux-next, and it has two ext_info > attributes that needs to be set differently for different mux > states. Two of the states need "invert" to be false, the rest need > "invert" to be true. And it is also preferable to have different > values for "compare_interval" for different mux states since the > signals on the diffrent mux states have the different frequency > characteristics. > > True, I could have the ext-info attributes go straight through > the mux, and just start by writing values to "invert" > and "compare_interval", and only then read a sample. But then I > would need to lock out other users during the duration of this > transaction. I believe that the best place to put that lock is > in the iio mux (when it locks its control-mux) and not leave it > to userspace to solve this in some brittle cooperative manner. > >> Perhaps an example of how it is used and what the resulting interface >> looks like? > > The resulting interface is just a copy of the (ext_info) interface > exposed by the parent channel (with a cache that is rewritten to > the parent on every iio mux state change). I have plans to add code > to not rewrite ext_info attributes that have never been changed in > any mux state. > > Below I have an example file listing. > > device0 is a dpot (mcp4561). > device1 is a dac (dpot-dac, wrapping the above dpot). > device2 is an adc (envelope-detector, wrapping the above dac) > device3 is a mux (iio-mux, wrapping the above adc) > > The 8-way iio-mux have no signals attached on mux states 0 and 1, which > is why the first channel for device 3 is in_altvoltage2. > > Ultimately, I would like some knob to hide devices 0, 1 and 2 from > userspace. They need/should only be visible to in-kernel users. Or > is there such a knob already? > There isn't and this feeds into what Lars was suggesting with a fabric driver. The complexity of the description in device tree is getting really very nasty indeed, perhaps we are better off allowing for complex cases to have a driver that directly hooks into all the relevant elements and can do magic channel remapping etc. That could then register the 3 muxes and acquire all the chanenls required to build a single many channel device that hides all the complexity from userspace. I've considered working out how to do an IIO multiplexer before in software which would allow us to make 'fake' devices that wrap multiple physical devices. In the general case it has always felt to complex as we'd want it to handle triggered and buffered data flows. That brings all sorts of nasty data alignment problems with it as there is no guarantee the devices are producing aligned data at all. In the specific case though a driver can bundle up everything it needs to create a pseudo device (for triggered flows we'd probably need a little magic to hold off the trigger but that's not hard). With sysfs only access it would be simple to do but hard to describe. Hence bringing us back to fabric drivers. Thanks for the description. Good to understand what you are trying to handle. Jonathan > Cheers, > Peter > > $ ls /sys/bus/iio/devices/iio\:device* > /sys/bus/iio/devices/iio:device0: > dev out_resistance_raw_available > name out_resistance_scale > of_node power > out_resistance0_raw subsystem > out_resistance1_raw uevent > > /sys/bus/iio/devices/iio:device1: > dev
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 23/11/16 11:47, Peter Rosin wrote: > On 2016-11-22 21:58, Lars-Peter Clausen wrote: >> On 11/21/2016 02:17 PM, Peter Rosin wrote: >> [...] >>> I have a piece of hardware that is using the same 3 GPIO pins >>> to control four 8-way muxes. Three of them control ADC lines >>> to an ADS1015 chip with an iio driver, and the last one >>> controls the SDA line of an i2c bus. We have some deployed >>> code to handle this, but you do not want to see it or ever >>> hear about it. I'm not sure why I even mention it. Anyway, >>> the situation has nagged me to no end for quite some time. >>> >>> So, after first getting more intimate with the i2c muxing code >>> and later discovering the drivers/iio/inkern.c file and >>> writing a couple of drivers making use of it, I came up with >>> what I think is an acceptable solution; add a generic mux >>> controller driver (and subsystem) that is shared between all >>> instances, and combine that with an iio mux driver and a new >>> generic i2c mux driver. The new i2c mux I called "simple" >>> since it is only hooking the i2c muxing and the new mux >>> controller (much like the alsa simple card driver does for ASoC). >> >> While abstracting this properly is all nice and good and the way it should >> be done, but it also adds a lot of complexity and the devicetree adds a lot >> of restrictions on what can actually be represented. > > This is a characterization without any specifics. But is the > characterization true? You have two complaints, complexity > and restrictions with bindings. > >> There is a certain point where the fabric on a PCB becomes so complex that >> it deserves to be a device on its own (like the audio fabric drivers). >> Especially when the hardware is built with a certain application in mind and >> the driver is supposed to impose policy which reflects this application. The >> latter can often not properly be described with the primitives the >> devicetree can offer. >> >> And I think your setup is very borderline what can be done in a declarative >> way only and it adds a lot of complexity over a more imperative solution in >> form of a driver. I think it is worth investigating about having a driver >> that is specific to your fabric and handles the interdependencies of the >> discrete components. > > So, there are three "new" concepts: > > 1. Sticking a mux in front of an AD-converter. That's not all that > novel, nor complex. Quite the opposite, I'd say. In fact, I find it > a bit amazing that there is no in-kernel support for it. As ever first person who needs it and has the skills to write it gets to do it ;) Congratulations Peter ;) > > 2. Reusing the same GPIO-pins to drive different muxes. There are > obviously chips that work this way (as Jonathan pointed out) and > these will at some point get used in Linux devices. I guess they > already are used, but that people handle them in userspace. Or > something? If this is complex, which I question, it will still need > support at some point. At least that's what I believe. > > 3. Using the same GPIO pins to mux things handled by different > subsystems. Right, this is a bit crazy, and I'd rather not have this > requirement, but this HW is what it is so I'll need to handle it in > some way. It is also what stops me from falling back to a userspace > solution, which is probably connected to why #1 and #2 is not supported > by the kernel; everybody probably does muxing in userspace. Which is > not necessarily a good idea, nor how it's supposed to be done... > > So, the only thing that's out of the ordinary (as I see it), is #3. > The question that then needs an answer is how the in-kernel solution > for #1 and #2 would look if we do not consider #3. > > And I claim that the desired solution to #1 and #2 is pretty close > to my proposal. > > A. You do not want mux-controller drivers in every subsystem that > needs them. Agreed. > > B. You do not want every mux-consumer to know the specifics of how to > operate every kind of mux; there are muxes that are not controlled > with GPIO pins... > > C. When you implement muxing in a subsystem, there will in some cases > be a need to handle parallel muxing, where there is a need to share > mux-controllers. > > It just feels right to separate out the mux-controller and refer to > it from where a mux is needed. It solves #1 and #2. And, of course, > as a bonus #3 is also solved. But my bias is obvious. > > And that leads us to the restrictions with the bindings. And the same > thing happens; the solution for #2 also solves #3. > > So how do you refer to a mux-controller from where it's needed? My > first proposal used a dt phandle, for the second round I put them in > the parent node. It would be super if it was possible for the mux- > consumer to create the mux-controller device from the same dt > node that is already bound to the mux-consumer. The problem is that > the mux-consumer should not hard-code which mux-controller device it > should create. Th
Re: [PATCH 1/3] hwmon: Add Texas Instruments TMP108 temperature sensor driver.
On 11/26/2016 09:15 PM, John Muir wrote:
Add support for the TI TMP108 temperature sensor with some device
configuration parameters.
Signed-off-by: John Muir
---
Documentation/devicetree/bindings/hwmon/tmp108.txt | 27 ++
Documentation/hwmon/tmp108 | 38 ++
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/tmp108.c | 429 +
5 files changed, 506 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/tmp108.txt
create mode 100644 Documentation/hwmon/tmp108
create mode 100644 drivers/hwmon/tmp108.c
diff --git a/Documentation/devicetree/bindings/hwmon/tmp108.txt
b/Documentation/devicetree/bindings/hwmon/tmp108.txt
This should be provided in a separate patch.
new file mode 100644
index 000..210af63
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/tmp108.txt
@@ -0,0 +1,27 @@
+TMP108 temperature sensor
+-
+
+This device supports I2C only.
+
+Requires node properties:
+- compatible : "ti,tmp108"
+- reg : the I2C address of the device. This is 0x48, 0x49, 0x4a, or 0x4b.
+
+Optional node properties:
+- ti,thermostat-mode-comparitor : (boolean) select the comparitor mode for the
s/comparitor/comparator/g
+ thermostat rather than the default interrupt-mode.
+- ti,alert-active-high : (boolean) make the alert pin active-high instead of
+ the default active-low.
The driver doesn't support interrupts/alerts. Do those properties really add
value ?
+- ti,conversion-rate-cHz : (integer, cHz) select the conversion frequency for
+ continuous mode, in centi-Hz: 25, 100 (default), 400, or 1600.
+- ti,hysteresis : (integer, C) select the hysteresis value: 0, 1, 2, or 4
+ (celcius).
+
We would nor mally make the conversion rate and hysteresis user configurable,
with the update_interval and temp1_{min,max}_hyst attributes. Those are not
really
system configuration properties.
+Example:
+ tmp108@48 {
+ compatible = "ti,tmp108";
+ reg = <0x48>;
+ ti,alert-active-high;
+ ti,hysteresis = <2>;
+ ti,conversion-rate-cHz = <25>;
+ };
diff --git a/Documentation/hwmon/tmp108 b/Documentation/hwmon/tmp108
new file mode 100644
index 000..ef2e9a3
--- /dev/null
+++ b/Documentation/hwmon/tmp108
@@ -0,0 +1,38 @@
+Kernel driver tmp108
+
+
+Supported chips:
+ * Texas Instruments TMP108
+Prefix: 'tmp108'
+Addresses scanned: none
+Datasheet: http://www.ti.com/product/tmp108
+
+Author:
+ John Muir
+
+Description
+---
+
+The Texas Instruments TMP108 implements one temperature sensor. An alert pin
+can be set when temperatures exceed minimum or maximum values plus or minus a
+hysteresis value.
+
+The sensor is accurate to 0.75C over the range of -25 to +85 C, and to 1.0
+degree from -40 to +125 C. Resolution of the sensor is 0.0625 degree. The
+operating temperature has a minimum of -55 C and a maximum of +150 C.
+Hysteresis values can be set to 0, 1, 2, or 4C.
+
+The TMP108 has a programmable update rate that can select between 8, 4, 1, and
+0.5 Hz.
+
+By default the TMP108 reads the temperature continuously. To conserve power,
+the TMP108 has a one-shot mode where the device is normally shut-down. When a
+one shot is requested the temperature is read, the result can be retrieved,
+and then the device is shut down automatically. (This driver only supports
+continuous mode.)
+
+The driver provides the common sysfs-interface for temperatures (see
+Documentation/hwmon/sysfs-interface under Temperatures).
+
+See Documentation/devicetree/bindings/hwmon/tmp108.txt for configuration
+properties.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d..4c173de 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1591,6 +1591,17 @@ config SENSORS_TMP103
This driver can also be built as a module. If so, the module
will be called tmp103.
+config SENSORS_TMP108
+ tristate "Texas Instruments TMP108"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ If you say yes here you get support for Texas Instruments TMP108
+ sensor chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called tmp108.
+
config SENSORS_TMP401
tristate "Texas Instruments TMP401 and compatibles"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba..51e5256 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -152,6 +152,7 @@ obj-$(CONFIG_SENSORS_TC74) += tc74.o
obj-$(CONFIG_SENSORS_THMC50) += thmc50.o
obj-$(CONFIG_SENSORS_TMP102) += tmp102.o
obj-$(CONFIG_SENSORS_TMP103) += tmp103.o
+obj-$(CONFIG_SENSORS_TMP108) += tmp108.o
obj-$(CONFIG_SENSORS_TMP401) += tmp401.o
obj-$(CONFIG_SENSORS_TMP421) +=
Re: [PATCH 2/3] hwmon: tmp108: Use devm variants of registration interfaces.
On 11/26/2016 09:15 PM, John Muir wrote:
From: John Muir
Use the devm hwmon and thermal zone registration functions to
clean up the code and remove the need for an i2c_driver.remove
callback.
Signed-off-by: John Muir
---
drivers/hwmon/tmp108.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/hwmon/tmp108.c b/drivers/hwmon/tmp108.c
index da64517..b13d652 100644
--- a/drivers/hwmon/tmp108.c
+++ b/drivers/hwmon/tmp108.c
@@ -83,8 +83,6 @@
struct tmp108 {
struct regmap *regmap;
- struct device *hwmon_dev;
- struct thermal_zone_device *tz;
u16 config;
unsigned long ready_time;
};
@@ -245,6 +243,7 @@ static int tmp108_probe(struct i2c_client *client,
{
struct device *dev = &client->dev;
struct device *hwmon_dev;
+ struct thermal_zone_device *tz;
struct tmp108 *tmp108;
unsigned int regval;
int err;
@@ -353,18 +352,18 @@ static int tmp108_probe(struct i2c_client *client,
if (err)
return err;
- hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
- tmp108, tmp108_groups);
+ hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
+ tmp108,
+ tmp108_groups);
if (IS_ERR(hwmon_dev)) {
dev_dbg(dev, "unable to register hwmon device\n");
return PTR_ERR(hwmon_dev);
}
- tmp108->hwmon_dev = hwmon_dev;
- tmp108->tz = thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
-&tmp108_of_thermal_ops);
- if (IS_ERR(tmp108->tz))
- return PTR_ERR(tmp108->tz);
+ tz = devm_thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
+ &tmp108_of_thermal_ops);
+ if (IS_ERR(tz))
+ return PTR_ERR(tz);
dev_info(dev, "%s, alert: active %s, hyst: %uC, conv: %ucHz\n",
(tmp108->config & TMP108_CONF_TM) != 0 ?
@@ -374,16 +373,6 @@ static int tmp108_probe(struct i2c_client *client,
return 0;
}
-static int tmp108_remove(struct i2c_client *client)
-{
- struct tmp108 *tmp108 = i2c_get_clientdata(client);
-
With this, i2c_set_clientdata() in the probe function is no longer needed.
- thermal_zone_of_sensor_unregister(tmp108->hwmon_dev, tmp108->tz);
- hwmon_device_unregister(tmp108->hwmon_dev);
-
- return 0;
-}
-
#ifdef CONFIG_PM_SLEEP
static int tmp108_suspend(struct device *dev)
{
@@ -418,7 +407,6 @@ static struct i2c_driver tmp108_driver = {
.driver.name= DRIVER_NAME,
.driver.pm = &tmp108_dev_pm_ops,
.probe = tmp108_probe,
- .remove = tmp108_remove,
.id_table = tmp108_id,
};
Re: [PATCH v3 3/3] zram: support BDI_CAP_STABLE_WRITES
On (11/26/16 23:41), Minchan Kim wrote: [..] > > > mutex_lock(&bdev->bd_mutex); > > > > why not set it just once, when we allocate queue/disk and configure both > > of them: in zram_add() > > I should have mentioned the reason. > The revalidate_disk reset the BDI_CAP_STABLE_WRITES. aha. either sets or clears it in blk_integrity_revalidate(), now I see it. -ss
Re: [HMM v13 08/18] mm/hmm: heterogeneous memory management (HMM for short)
On Wed, Nov 23, 2016 at 09:33:35AM +0530, Anshuman Khandual wrote:
> On 11/18/2016 11:48 PM, Jérôme Glisse wrote:
[...]
> > + *
> > + * hmm_vma_migrate(vma, start, end, ops);
> > + *
> > + * With ops struct providing 2 callback alloc_and_copy() which allocated
> > the
> > + * destination memory and initialize it using source memory. Migration can
> > fail
> > + * after this step and thus last callback finalize_and_map() allow the
> > device
> > + * driver to know which page were successfully migrated and which were not.
>
> So we have page->pgmap->free_devpage() to release the individual page back
> into the device driver management during migration and also we have this ops
> based finalize_and_mmap() to check on the failed instances inside a single
> migration context which can contain set of pages at a time.
>
> > + *
> > + * This can easily be use outside of HMM intended use case.
>
> Where you think this can be used outside of HMM ?
Well on the radar is new memory hierarchy that seems to be on every CPU designer
roadmap. Where you have a fast small HBM like memory package with the CPU and
then
you have the regular memory.
In the embedded world they want to migrate active process to fast CPU memory and
shutdown the regular memory to save power.
In the HPC world they want to migrate hot data of hot process to this fast
memory.
In both case we are talking about process base memory migration and in case of
embedded they also have DMA engine they can use to offload the copy operation
itself.
This are the useful case i have in mind but other people might see that code and
realise they could also use it for their own specific corner case.
[...]
> > +/*
> > + * hmm_pfn_t - HMM use its own pfn type to keep several flags per page
> > + *
> > + * Flags:
> > + * HMM_PFN_VALID: pfn is valid
> > + * HMM_PFN_WRITE: CPU page table have the write permission set
> > + */
> > +typedef unsigned long hmm_pfn_t;
> > +
> > +#define HMM_PFN_VALID (1 << 0)
> > +#define HMM_PFN_WRITE (1 << 1)
> > +#define HMM_PFN_SHIFT 2
> > +
> > +static inline struct page *hmm_pfn_to_page(hmm_pfn_t pfn)
> > +{
> > + if (!(pfn & HMM_PFN_VALID))
> > + return NULL;
> > + return pfn_to_page(pfn >> HMM_PFN_SHIFT);
> > +}
> > +
> > +static inline unsigned long hmm_pfn_to_pfn(hmm_pfn_t pfn)
> > +{
> > + if (!(pfn & HMM_PFN_VALID))
> > + return -1UL;
> > + return (pfn >> HMM_PFN_SHIFT);
> > +}
> > +
> > +static inline hmm_pfn_t hmm_pfn_from_page(struct page *page)
> > +{
> > + return (page_to_pfn(page) << HMM_PFN_SHIFT) | HMM_PFN_VALID;
> > +}
> > +
> > +static inline hmm_pfn_t hmm_pfn_from_pfn(unsigned long pfn)
> > +{
> > + return (pfn << HMM_PFN_SHIFT) | HMM_PFN_VALID;
> > +}
>
> Hmm, so if we use last two bits on PFN as flags, it does reduce the number of
> bits available for the actual PFN range. But given that we support maximum of
> 64TB on POWER (not sure about X86) we can live with this two bits going away
> from the unsigned long. But what is the purpose of tracking validity and write
> flag inside the PFN ?
So 2^46 so with 12bits PAGE_SHIFT we only need 34 bits for pfns value hence i
should have enough place for my flag or is unsigned long not 64bits on powerpc ?
Cheers,
Jérôme
[PATCH] mm: page_alloc: High-order per-cpu page allocator v3
Changelog since v2 o Correct initialisation to avoid -Woverflow warning SLUB has been the default small kernel object allocator for quite some time but it is not universally used due to performance concerns and a reliance on high-order pages. The high-order concerns has two major components -- high-order pages are not always available and high-order page allocations potentially contend on the zone->lock. This patch addresses some concerns about the zone lock contention by extending the per-cpu page allocator to cache high-order pages. The patch makes the following modifications o New per-cpu lists are added to cache the high-order pages. This increases the cache footprint of the per-cpu allocator and overall usage but for some workloads, this will be offset by reduced contention on zone->lock. The first MIGRATE_PCPTYPE entries in the list are per-migratetype. The remaining are high-order caches up to and including PAGE_ALLOC_COSTLY_ORDER o pcp accounting during free is now confined to free_pcppages_bulk as it's impossible for the caller to know exactly how many pages were freed. Due to the high-order caches, the number of pages drained for a request is no longer precise. o The high watermark for per-cpu pages is increased to reduce the probability that a single refill causes a drain on the next free. The benefit depends on both the workload and the machine as ultimately the determining factor is whether cache line bounces on zone->lock or contention is a problem. The patch was tested on a variety of workloads and machines, some of which are reported here. This is the result from netperf running UDP_STREAM on localhost. It was selected on the basis that it is slab-intensive and has been the subject of previous SLAB vs SLUB comparisons with the caveat that this is not testing between two physical hosts. 2-socket modern machine 4.9.0-rc5 4.9.0-rc5 vanilla hopcpu-v3 Hmeansend-64 178.38 ( 0.00%) 256.74 ( 43.93%) Hmeansend-128351.49 ( 0.00%) 507.52 ( 44.39%) Hmeansend-256671.23 ( 0.00%) 1004.19 ( 49.60%) Hmeansend-1024 2663.60 ( 0.00%) 3910.42 ( 46.81%) Hmeansend-2048 5126.53 ( 0.00%) 7562.13 ( 47.51%) Hmeansend-3312 7949.99 ( 0.00%)11565.98 ( 45.48%) Hmeansend-4096 9433.56 ( 0.00%)12929.67 ( 37.06%) Hmeansend-8192 15940.64 ( 0.00%)21587.63 ( 35.43%) Hmeansend-1638426699.54 ( 0.00%)32013.79 ( 19.90%) Hmeanrecv-64 178.38 ( 0.00%) 256.72 ( 43.92%) Hmeanrecv-128351.49 ( 0.00%) 507.47 ( 44.38%) Hmeanrecv-256671.20 ( 0.00%) 1003.95 ( 49.57%) Hmeanrecv-1024 2663.45 ( 0.00%) 3909.70 ( 46.79%) Hmeanrecv-2048 5126.26 ( 0.00%) 7560.67 ( 47.49%) Hmeanrecv-3312 7949.50 ( 0.00%)11564.63 ( 45.48%) Hmeanrecv-4096 9433.04 ( 0.00%)12927.48 ( 37.04%) Hmeanrecv-8192 15939.64 ( 0.00%)21584.59 ( 35.41%) Hmeanrecv-1638426698.44 ( 0.00%)32009.77 ( 19.89%) 1-socket 6 year old machine 4.9.0-rc5 4.9.0-rc5 vanilla hopcpu-v3 Hmeansend-64 87.47 ( 0.00%) 127.14 ( 45.36%) Hmeansend-128174.36 ( 0.00%) 256.42 ( 47.06%) Hmeansend-256347.52 ( 0.00%) 509.41 ( 46.59%) Hmeansend-1024 1363.03 ( 0.00%) 1991.54 ( 46.11%) Hmeansend-2048 2632.68 ( 0.00%) 3759.51 ( 42.80%) Hmeansend-3312 4123.19 ( 0.00%) 5873.28 ( 42.45%) Hmeansend-4096 5056.48 ( 0.00%) 7072.81 ( 39.88%) Hmeansend-8192 8784.22 ( 0.00%)12143.92 ( 38.25%) Hmeansend-1638415081.60 ( 0.00%)19812.71 ( 31.37%) Hmeanrecv-64 86.19 ( 0.00%) 126.59 ( 46.87%) Hmeanrecv-128173.93 ( 0.00%) 255.21 ( 46.73%) Hmeanrecv-256346.19 ( 0.00%) 506.72 ( 46.37%) Hmeanrecv-1024 1358.28 ( 0.00%) 1980.03 ( 45.77%) Hmeanrecv-2048 2623.45 ( 0.00%) 3729.35 ( 42.15%) Hmeanrecv-3312 4108.63 ( 0.00%) 5831.47 ( 41.93%) Hmeanrecv-4096 5037.25 ( 0.00%) 7021.59 ( 39.39%) Hmeanrecv-8192 8762.32 ( 0.00%)12072.44 ( 37.78%) Hmeanrecv-1638415042.36 ( 0.00%)19690.14 ( 30.90%) This is somewhat dramatic but it's also not universal. For example, it was observed on an older HP machine using pcc-cpufreq that there was almost no difference but pcc-cpufreq is also a known performance hazard. These are quite different results but illustrate that the patch is dependent on the CPU. The results are similar for TCP_STREAM on the two-socket machine. The observations on sockperf are different. 2-socket modern machine sockperf-tcp-throughput 4.9.0-rc5 4.9.0-rc5
Re: [PATCH v3 1/3] mm: support anonymous stable page
Hi, On (11/25/16 17:35), Minchan Kim wrote: [..] > Unfortunately, zram has used per-cpu stream feature from v4.7. > It aims for increasing cache hit ratio of scratch buffer for > compressing. Downside of that approach is that zram should ask > memory space for compressed page in per-cpu context which requires > stricted gfp flag which could be failed. If so, it retries to > allocate memory space out of per-cpu context so it could get memory > this time and compress the data again, copies it to the memory space. > > In this scenario, zram assumes the data should never be changed > but it is not true unless stable page supports. So, If the data is > changed under us, zram can make buffer overrun because second > compression size could be bigger than one we got in previous trial > and blindly, copy bigger size object to smaller buffer which is > buffer overrun. The overrun breaks zsmalloc free object chaining > so system goes crash like above. very interesting find! didn't see this coming. > Unfortunately, reuse_swap_page should be atomic so that we cannot wait on > writeback in there so the approach in this patch is simply return false if > we found it needs stable page. Although it increases memory footprint > temporarily, it happens rarely and it should be reclaimed easily althoug > it happened. Also, It would be better than waiting of IO completion, > which is critial path for application latency. wondering - how many pages can it hold? we are in low memory, that's why we failed to zsmalloc in fast path, so how likely this to worsen memory pressure? just asking. in async zram the window between zram_rw_page() and actual write of a page even bigger, isn't it? we *probably* and *may be* can try handle it in zram: -- store the previous clen before re-compression -- check if new clen > saved_clen and if it is - we can't use previously allocate handle and need to allocate a new one again. if it's less or equal than the saved one - store the object (wasting some space, yes. but we are in low mem). -- we, may be, also can try harder in zsmalloc. once we detected that zsmllaoc has failed, then we can declare it as an emergency and store objects of size X in higher classes (assuming that there is a bigger size class available with allocated and unused object). -ss
Re: [PATCH 01/39] mtd: nand: allow to set only one of ECC size and ECC strength from DT
On Sun, 27 Nov 2016 03:05:47 +0900
Masahiro Yamada wrote:
> Currently, it is valid to specify both "nand-ecc-step-size" and
> "nand-ecc-strength", but not allowed to set only one of them.
>
> This requirement has a conflict with "nand-ecc-maximize"; this flag
> is used when you want the driver to choose the best ECC strength.
> If "nand-ecc-maximize" is set, "nand-ecc-strength" is very likely to
> be unset.
Well, when I added nand-ecc-maximize I was assuming that the driver
would choose both step-size and strength to maximize the ECC strength
on the whole page, but you're right, we might need fine-grained
tweaking (forcing the step-size but letting the driver choose the ECC
strength).
>
> It would be possible to make the if-conditional more complex by
> adding the check for the NAND_ECC_MAXIMIZE flag, but I chose to drop
> the check entirely. I thought of the situation where the hardware
> has a fixed ECC step size (so it can be hard-coded in the driver),
> whereas the ECC strength is configurable by software. In that case,
> we may want to only set "nand-ecc-strength" (or "nand-ecc-maximize")
> in DT.
I would also add that checking things at this level is not really
relevant. The driver is likely to check the ecc.size and ecc.strength
values anyway, and pick a default value (chip->nand_ecc_xx_ds or some
hard-coded values if the ECC engine only support one specific case) if
one of them is unassigned (left to 0).
I'll let some time for others to review before queuing this patch for
4.11.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> The Denali NAND is the case.
>
> The ecc.size is fixed when the RTL is delivered, while the
> driver can choose ecc.strength from some supported values.
>
> For Intel and Altera, available ecc.strength are 8, 15.
> For Socionext UniPhier, available ecc.strength are 8, 16, 24.
>
>
> drivers/mtd/nand/nand_base.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 8c74d8c..c1ed91d 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -4266,12 +4266,6 @@ static int nand_dt_init(struct nand_chip *chip)
> ecc_strength = of_get_nand_ecc_strength(dn);
> ecc_step = of_get_nand_ecc_step_size(dn);
>
> - if ((ecc_step >= 0 && !(ecc_strength >= 0)) ||
> - (!(ecc_step >= 0) && ecc_strength >= 0)) {
> - pr_err("must set both strength and step size in DT\n");
> - return -EINVAL;
> - }
> -
> if (ecc_mode >= 0)
> chip->ecc.mode = ecc_mode;
>
Re: Enabling peer to peer device transactions for PCIe devices
Am 27.11.2016 um 15:02 schrieb Haggai Eran: On 11/25/2016 9:32 PM, Jason Gunthorpe wrote: On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote: Like you say below we have to handle short lived in the usual way, and that covers basically every device except IB MRs, including the command queue on a NVMe drive. Well a problem which wasn't mentioned so far is that while GPUs do have a page table to mirror the CPU page table, they usually can't recover from page faults. So what we do is making sure that all memory accessed by the GPU Jobs stays in place while those jobs run (pretty much the same pinning you do for the DMA). Yes, it is DMA, so this is a valid approach. But, you don't need page faults from the GPU to do proper coherent page table mirroring. Basically when the driver submits the work to the GPU it 'faults' the pages into the CPU and mirror translation table (instead of pinning). Like in ODP, MMU notifiers/HMM are used to monitor for translation changes. If a change comes in the GPU driver checks if an executing command is touching those pages and blocks the MMU notifier until the command flushes, then unfaults the page (blocking future commands) and unblocks the mmu notifier. I think blocking mmu notifiers against something that is basically controlled by user-space can be problematic. This can block things like memory reclaim. If you have user-space access to the device's queues, user-space can block the mmu notifier forever. Really good point. I think this means the bare minimum if we don't have recoverable page faults is to have preemption support like Felix described in his answer as well. Going to keep that in mind, Christian.
Re: [PATCH v2 1/7] MFD: add bindings for stm32 general purpose timer driver
On 24/11/16 15:14, Benjamin Gaignard wrote:
> Add bindings information for stm32 general purpose timer
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard
> ---
> .../bindings/mfd/stm32-general-purpose-timer.txt | 43
> ++
> 1 file changed, 43 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>
> diff --git
> a/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> new file mode 100644
> index 000..2f10e67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> @@ -0,0 +1,43 @@
> +STM32 general purpose timer driver
> +
> +Required parameters:
> +- compatible: must be "st,stm32-gptimer"
> +
> +- reg: Physical base address and length of the
> controller's
> + registers.
> +- clock-names: Set to "clk_int".
> +- clocks:Phandle to the clock used by the timer module.
> + For Clk properties, please refer to
> ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets:Phandle to the parent reset controller.
> + See ..reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm: See ../pwm/pwm-stm32.txt
> +- iiotimer: See ../iio/timer/stm32-iio-timer.txt
Naming issue here. Can't mention IIO as that's a linux subsystem and all
bindings must be independent of OS.
Perhaps adc-trigger-timer?
> +
> +Example:
> + gptimer1: gptimer1@4001 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x4001 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1@0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> +
> + iiotimer1@0 {
> + compatible = "st,stm32-iio-timer";
Again, avoid the use of iio in here (same issue you had with mfd in the previous
version).
> + interrupts = <27>;
> + st,input-triggers-names = TIM5_TRGO,
Docs for these should be introduced before they are used in an example.
Same for the PWM ones above. Expand the detail fo the example as you add
the other elements.
> + TIM2_TRGO,
> + TIM4_TRGO,
> + TIM3_TRGO;
> + st,output-triggers-names = TIM1_TRGO;
> + };
> + };
>
Re: [PATCH v2 3/7] PWM: add pwm-stm32 DT bindings
On 24/11/16 15:14, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 37
> ++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 000..36263f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,37 @@
> +STMicroelectronics PWM driver bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
> +
> +Required parameters:
> +- compatible:Must be "st,stm32-pwm"
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration
> nodes
> + for PWM module.
> + For Pinctrl properties, please refer to [1].
> +
> +Optional parameters:
> +- st,breakinput: Set if the hardware have break input capabilities
> +- st,breakinput-polarity: Set break input polarity. Default is 0
> + The value define the active polarity:
> + - 0 (active LOW)
> + - 1 (active HIGH)
> +- st,pwm-num-chan: Number of available PWM channels. Default is 0.
> +- st,32bits-counter: Set if the hardware have a 32 bits counter
> +- st,complementary: Set if the hardware have complementary output channels
> +
> +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +
> +Example:
> + gptimer1: gptimer1@4001 {
Given the example includes chunks for the other binding, make sure to have
explicit cross references in the document.
> + compatible = "st,stm32-gptimer";
> + reg = <0x4001 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1@0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> + };
>
Re: [PATCH v2 5/7] IIO: add bindings for stm32 IIO timer driver
On 24/11/16 15:14, Benjamin Gaignard wrote:
> Define bindings for stm32 IIO timer
>
> version 2:
> - only keep one compatible
> - add DT parameters to set lists of the triggers:
> one list describe the triggers created by the device
> another one give the triggers accepted by the device
>
> Signed-off-by: Benjamin Gaignard
> ---
> .../bindings/iio/timer/stm32-iio-timer.txt | 41
> ++
> 1 file changed, 41 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
> b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
> new file mode 100644
> index 000..840b417
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
> @@ -0,0 +1,41 @@
> +timer IIO trigger bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
Add a cross reference...
> +
> +Required parameters:
> +- compatible:must be "st,stm32-iio-timer"
st,stm32-adc-timer or something like that.
> +- interrupts:Interrupt for this device
> + See ../interrupt-controller/st,stm32-exti.txt
> +
> +Optional parameters:
> +- st,input-triggers-names: List of the possible input triggers for
> + the device
> +- st,output-triggers-names: List of the possible output triggers for
> + the device
What are input / output triggers?
> +
> +Possible triggers are defined in
> include/dt-bindings/iio/timer/st,stm32-iio-timer.h
> +
> +Example:
> + gptimer1: gptimer1@4001 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x4001 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1@0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> +
> + iiotimer1@0 {
> + compatible = "st,stm32-iio-timer";
> + interrupts = <27>;
> + st,input-triggers-names = TIM5_TRGO,
> + TIM2_TRGO,
> + TIM4_TRGO,
> + TIM3_TRGO;
> + st,output-triggers-names = TIM1_TRGO;
> + };
> + };
>
Re: Enabling peer to peer device transactions for PCIe devices
On 11/25/2016 9:32 PM, Jason Gunthorpe wrote: > On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote: > >>> Like you say below we have to handle short lived in the usual way, and >>> that covers basically every device except IB MRs, including the >>> command queue on a NVMe drive. >> >> Well a problem which wasn't mentioned so far is that while GPUs do have a >> page table to mirror the CPU page table, they usually can't recover from >> page faults. > >> So what we do is making sure that all memory accessed by the GPU Jobs stays >> in place while those jobs run (pretty much the same pinning you do for the >> DMA). > > Yes, it is DMA, so this is a valid approach. > > But, you don't need page faults from the GPU to do proper coherent > page table mirroring. Basically when the driver submits the work to > the GPU it 'faults' the pages into the CPU and mirror translation > table (instead of pinning). > > Like in ODP, MMU notifiers/HMM are used to monitor for translation > changes. If a change comes in the GPU driver checks if an executing > command is touching those pages and blocks the MMU notifier until the > command flushes, then unfaults the page (blocking future commands) and > unblocks the mmu notifier. I think blocking mmu notifiers against something that is basically controlled by user-space can be problematic. This can block things like memory reclaim. If you have user-space access to the device's queues, user-space can block the mmu notifier forever. On PeerDirect, we have some kind of a middle-ground solution for pinning GPU memory. We create a non-ODP MR pointing to VRAM but rely on user-space and the GPU not to migrate it. If they do, the MR gets destroyed immediately. This should work on legacy devices without ODP support, and allows the system to safely terminate a process that misbehaves. The downside of course is that it cannot transparently migrate memory but I think for user-space RDMA doing that transparently requires hardware support for paging, via something like HMM. ... > I'm hearing most people say ZONE_DEVICE is the way to handle this, > which means the missing remaing piece for RDMA is some kind of DMA > core support for p2p address translation.. Yes, this is definitely something we need. I think Will Davis's patches are a good start. Another thing I think is that while HMM is good for user-space applications, for kernel p2p use there is no need for that. Using ZONE_DEVICE with or without something like DMA-BUF to pin and unpin pages for the short duration as you wrote above could work fine for kernel uses in which we can guarantee they are short. Haggai
Re: Enabling peer to peer device transactions for PCIe devices
On 11/25/2016 9:32 PM, Jason Gunthorpe wrote: > On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote: > >>> Like you say below we have to handle short lived in the usual way, and >>> that covers basically every device except IB MRs, including the >>> command queue on a NVMe drive. >> >> Well a problem which wasn't mentioned so far is that while GPUs do have a >> page table to mirror the CPU page table, they usually can't recover from >> page faults. > >> So what we do is making sure that all memory accessed by the GPU Jobs stays >> in place while those jobs run (pretty much the same pinning you do for the >> DMA). > > Yes, it is DMA, so this is a valid approach. > > But, you don't need page faults from the GPU to do proper coherent > page table mirroring. Basically when the driver submits the work to > the GPU it 'faults' the pages into the CPU and mirror translation > table (instead of pinning). > > Like in ODP, MMU notifiers/HMM are used to monitor for translation > changes. If a change comes in the GPU driver checks if an executing > command is touching those pages and blocks the MMU notifier until the > command flushes, then unfaults the page (blocking future commands) and > unblocks the mmu notifier. I think blocking mmu notifiers against something that is basically controlled by user-space can be problematic. This can block things like memory reclaim. If you have user-space access to the device's queues, user-space can block the mmu notifier forever. On PeerDirect, we have some kind of a middle-ground solution for pinning GPU memory. We create a non-ODP MR pointing to VRAM but rely on user-space and the GPU not to migrate it. If they do, the MR gets destroyed immediately. This should work on legacy devices without ODP support, and allows the system to safely terminate a process that misbehaves. The downside of course is that it cannot transparently migrate memory but I think for user-space RDMA doing that transparently requires hardware support for paging, via something like HMM. ... > I'm hearing most people say ZONE_DEVICE is the way to handle this, > which means the missing remaing piece for RDMA is some kind of DMA > core support for p2p address translation.. Yes, this is definitely something we need. I think Will Davis's patches are a good start. Another thing I think is that while HMM is good for user-space applications, for kernel p2p use there is no need for that. Using ZONE_DEVICE with or without something like DMA-BUF to pin and unpin pages for the short duration as you wrote above could work fine for kernel uses in which we can guarantee they are short. Haggai
Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup
Hi Peter, > On Fri, Nov 25, 2016 at 03:59:45PM +0100, Silvio Fricke wrote: > > ... and move to core-api folder. > > > > Signed-off-by: Silvio Fricke > > --- > > Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | > > 777 +--- > > Documentation/core-api/index.rst | > > 1 +- > > Documentation/process/volatile-considered-harmful.rst | > > 3 +- > > 3 files changed, 404 insertions(+), 377 deletions(-) > > Not a fan of this. The atomic_ops.txt file needs a lot of love, and I > wouldn't want to edit a .rst file. What is the problem with this rst-file? atomic_ops.rst are not so different to the txt variant. I will drop this patch. Best regards, Silvio -- -- S. Fricke sil...@port1024.net -- Diplom-Informatiker (FH) Linux-Development Matrix: @silvio:port1024.net
Re: [PATCH] USB: EHCI: ehci-w90x900: remove unuseful functions
On Thu, 24 Nov 2016 csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar
>
> The ehci_w90x900_probe function is not doing anything other than
> calling usb_w90x900_probe function so ehci_w90x900_probe function
> is unuseful that is why removed ehci_w90x900_probe functions and
> renamed usb_w90x900_probe function to ehci_w90x900_probe for proper
> naming.
>
> The ehci_w90x900_remove function is also not doing anything other
> than calling usb_w90x900_remove that is why removed ehci_w90x900_remove
> function and renamed usb_w90x900_remove to ehci_w90x900_remove for proper
> naming.
>
> This also removes warning of checkpatch.pl script.
>
> Signed-off-by: Manjunath Goudar
> Cc: Arnd Bergmann
> Cc: Greg KH
> Cc: Alan Stern
> Cc: Wan ZongShun
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
Acked-by: Alan Stern
> drivers/usb/host/ehci-w90x900.c | 30 --
> 1 file changed, 8 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-w90x900.c b/drivers/usb/host/ehci-w90x900.c
> index e42a29e..63b9d0c 100644
> --- a/drivers/usb/host/ehci-w90x900.c
> +++ b/drivers/usb/host/ehci-w90x900.c
> @@ -33,8 +33,7 @@ static const char hcd_name[] = "ehci-w90x900 ";
>
> static struct hc_driver __read_mostly ehci_w90x900_hc_driver;
>
> -static int usb_w90x900_probe(const struct hc_driver *driver,
> - struct platform_device *pdev)
> +static int ehci_w90x900_probe(struct platform_device *pdev)
> {
> struct usb_hcd *hcd;
> struct ehci_hcd *ehci;
> @@ -42,7 +41,8 @@ static int usb_w90x900_probe(const struct hc_driver *driver,
> int retval = 0, irq;
> unsigned long val;
>
> - hcd = usb_create_hcd(driver, &pdev->dev, "w90x900 EHCI");
> + hcd = usb_create_hcd(&ehci_w90x900_hc_driver,
> + &pdev->dev, "w90x900 EHCI");
> if (!hcd) {
> retval = -ENOMEM;
> goto err1;
> @@ -63,9 +63,9 @@ static int usb_w90x900_probe(const struct hc_driver *driver,
> HC_LENGTH(ehci, ehci_readl(ehci, &ehci->caps->hc_capbase));
>
> /* enable PHY 0,1,the regs only apply to w90p910
> - * 0xA4,0xA8 were offsets of PHY0 and PHY1 controller of
> - * w90p910 IC relative to ehci->regs.
> - */
> + * 0xA4,0xA8 were offsets of PHY0 and PHY1 controller of
> + * w90p910 IC relative to ehci->regs.
> + */
> val = __raw_readl(ehci->regs+PHY0_CTR);
> val |= ENPHY;
> __raw_writel(val, ehci->regs+PHY0_CTR);
> @@ -92,26 +92,12 @@ static int usb_w90x900_probe(const struct hc_driver
> *driver,
> return retval;
> }
>
> -static void usb_w90x900_remove(struct usb_hcd *hcd,
> - struct platform_device *pdev)
> -{
> - usb_remove_hcd(hcd);
> - usb_put_hcd(hcd);
> -}
> -
> -static int ehci_w90x900_probe(struct platform_device *pdev)
> -{
> - if (usb_disabled())
> - return -ENODEV;
> -
> - return usb_w90x900_probe(&ehci_w90x900_hc_driver, pdev);
> -}
> -
> static int ehci_w90x900_remove(struct platform_device *pdev)
> {
> struct usb_hcd *hcd = platform_get_drvdata(pdev);
>
> - usb_w90x900_remove(hcd, pdev);
> + usb_remove_hcd(hcd);
> + usb_put_hcd(hcd);
>
> return 0;
> }
Re: [PATCH 00/39] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb
+Andy
Hi Masahiro,
On Sun, 27 Nov 2016 03:05:46 +0900
Masahiro Yamada wrote:
> As I said in the 1st round series, I am tackling on this driver
> to use it for my SoCs.
>
> The previous series was just cosmetic things, but this series
> includes *real* changes.
>
> After some more cleanups, I will start to add changes that
> are really necessary.
> One of the biggest problems I want to solve is a bunch of
> hard-coded parameters that prevent me from using this driver for
> my SoCs.
>
> I will introduce capability flags that are associated with DT
> compatible and make platform-dependent parameters overridable.
>
> I still have lots of reworks to get done (so probably 3rd round
> series will come), but I hope it is getting better and
> I am showing a big picture now.
>
Thanks for posting this 2nd round of patches, I know have a clearer
view of what you're trying to achieve.
Could you be a bit more specific about the remaining rework (your 3rd
round)?
Also, if you don't mind, I'd like to have reviews and testing from intel
users before applying the series. Can you Cc Andy (and possibly other
intel maintainers) for the next round.
Thanks,
Boris
>
>
> Masahiro Yamada (39):
> mtd: nand: allow to set only one of ECC size and ECC strength from DT
> mtd: nand: denali: remove unused CONFIG option and macros
> mtd: nand: denali: remove redundant define of BANK(x)
> mtd: nand: denali: remove more unused struct members
> mtd: nand: denali: fix comment of denali_nand_info::flash_mem
> mtd: nand: denali: fix write_oob_data() function
> mtd: nand: denali: transfer OOB only when oob_required is set
> mtd: nand: denali: introduce capability flag
> mtd: nand: denali: fix erased page check code
> mtd: nand: denali: remove redundant if conditional of erased_check
> mtd: nand: denali: increment ecc_stats.failed by one per error
> mtd: nand: denali: return 0 for uncorrectable ECC error
> mtd: nand: denali: increment ecc_stats->corrected
> mtd: nand: denali: replace uint{8/16/32}_t with u{8/16/32}
> mtd: nand: denali: improve readability of handle_ecc()
> mtd: nand: denali: rename handle_ecc() to denali_sw_ecc_fixup()
> mtd: nand: denali: support HW_ECC_FIXUP capability
> mtd: nand: denali: move denali_read_page_raw() above
> denali_read_page()
> mtd: nand: denali: perform erased check against raw transferred page
> mtd: nand: denali_dt: enable HW_ECC_FIXUP capability for DT platform
> mtd: nand: denali: support 64bit capable DMA engine
> mtd: nand: denali_dt: remove dma-mask DT property
> mtd: nand: denali_dt: use pdev instead of ofdev for platform_device
> mtd: nand: denali: add NEW_N_BANKS_FORMAT capability
> mtd: nand: denali: use nand_chip to hold frequently accessed data
> mtd: nand: denali: call nand_set_flash_node() to set DT node
> mtd: nand: denali: do not set mtd->name
> mtd: nand: denali: move multi NAND fixup code to a helper function
> mtd: nand: denali: refactor multi NAND fixup code in more generic way
> mtd: nand: denali: set DEVICES_CONNECTED 1 if not set
> mtd: nand: denali: remove meaningless writes to read-only registers
> mtd: nand: denali: remove unnecessary writes to ECC_CORRECTION
> mtd: nand: denali: support 1024 byte ECC step size
> mtd: nand: denali: fix the condition for 15 bit ECC strength
> mtd: nand: denali: calculate ecc.strength and ecc.bytes generically
> mtd: nand: denali: allow to use SoC-specific ECC strength
> mtd: nand: denali: support "nand-ecc-strength" DT property
> mtd: nand: denali: remove Toshiba, Hynix specific fixup code
> mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
>
> .../devicetree/bindings/mtd/denali-nand.txt| 19 +-
> drivers/mtd/nand/Kconfig | 11 -
> drivers/mtd/nand/denali.c | 740
> -
> drivers/mtd/nand/denali.h | 84 +--
> drivers/mtd/nand/denali_dt.c | 95 ++-
> drivers/mtd/nand/denali_pci.c | 2 +
> drivers/mtd/nand/nand_base.c | 6 -
> 7 files changed, 515 insertions(+), 442 deletions(-)
>
Re: [PATCH 04/39] mtd: nand: denali: remove more unused struct members
On Sun, 27 Nov 2016 03:05:50 +0900
Masahiro Yamada wrote:
Please add a description here.
Also, this commit tends to validate my fears: you should have wait for
the full rework/cleanup to be done before submitting the first round of
cleanups. Indeed, commit c4ae0977f57d ("mtd: nand: denali: remove unused
struct member denali_nand_info::idx") was removing one of these unused
fields, leaving 2 of them behind.
While I like when things I clearly separated in different commits, when
you push the logic too far, you end up with big series which are not
necessarily easier to review, and several commits that are achieving
the same goal...
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
> index fd1ae08..4fad43b 100644
> --- a/drivers/mtd/nand/denali.h
> +++ b/drivers/mtd/nand/denali.h
> @@ -407,7 +407,6 @@ struct denali_nand_info {
> struct nand_buf buf;
> struct device *dev;
> int total_used_banks;
> - uint32_t block; /* stored for future use */
> uint16_t page;
> void __iomem *flash_reg; /* Mapped io reg base address */
> void __iomem *flash_mem; /* Mapped io reg base address */
> @@ -416,7 +415,6 @@ struct denali_nand_info {
> struct completion complete;
> spinlock_t irq_lock;
> uint32_t irq_status;
> - int irq_debug_array[32];
> int irq;
>
> uint32_t devnum;/* represent how many nands connected */
Re: [PATCH 09/39] mtd: nand: denali: fix erased page check code
On Sun, 27 Nov 2016 03:05:55 +0900
Masahiro Yamada wrote:
> Currently, is_erased() is called against "buf" twice, so the second
> call is meaningless. The second one should be checked against
> chip->oob_poi.
>
IMO, patch 9 to 12 should be squashed in a single patch. All you're
doing in these patch is fixing the check_erased_page logic.
You can describe the different broken thing in the commit message, but
splitting things as you do does not help much.
Also, please have at nand_check_erased_ecc_chunk() [1] instead of using
a private method (is_erased()) to check if the page is erased.
With this method you get bitflips in erased pages correction for free.
[1]http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_base.c#L1212
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index cbc7f75..753e9a02 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1160,7 +1160,7 @@ static int denali_read_page(struct mtd_info *mtd,
> struct nand_chip *chip,
> if (check_erased_page) {
> if (!is_erased(buf, mtd->writesize))
> mtd->ecc_stats.failed++;
> - if (!is_erased(buf, mtd->oobsize))
> + if (!is_erased(chip->oob_poi, mtd->oobsize))
> mtd->ecc_stats.failed++;
> }
> }
Re: [PATCH 13/39] mtd: nand: denali: increment ecc_stats->corrected
On Sun, 27 Nov 2016 03:05:59 +0900 Masahiro Yamada wrote: > Update the number of corrected bit flips when read_page() succeeds. > > Signed-off-by: Masahiro Yamada > --- > > drivers/mtd/nand/denali.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c > index a6445d9..4cc8945 100644 > --- a/drivers/mtd/nand/denali.c > +++ b/drivers/mtd/nand/denali.c > @@ -1162,6 +1162,9 @@ static int denali_read_page(struct mtd_info *mtd, > struct nand_chip *chip, > mtd->ecc_stats.failed++; > return 0; > } > + > + mtd->ecc_stats.corrected += max_bitflips; First of all, ecc_stats.corrected should contain the total number of bitflips detected on the MTD device, here you're just adding the maximum number of bitflips per ECC chunk for the current page, which is slightly different. Then, ecc_stats.corrected seems to be properly updated in handle_ecc() [1], so I see no reason to do it here. [1]http://lxr.free-electrons.com/source/drivers/mtd/nand/denali.c#L1003 > + > return max_bitflips; > } >
Re: [PATCH 15/39] mtd: nand: denali: improve readability of handle_ecc()
On Sun, 27 Nov 2016 03:06:01 +0900
Masahiro Yamada wrote:
> This function is unreadable due to the deep nesting. Note this
> function does a job only when INTR_STATUS__ECC_ERR is set.
> So, if the flag is not set, let it bail-out.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.c | 119
> +++---
> 1 file changed, 59 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index a7dc692..b577560 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -908,69 +908,68 @@ static bool handle_ecc(struct denali_nand_info *denali,
> u8 *buf,
> {
> bool check_erased_page = false;
> unsigned int bitflips = 0;
> + u32 err_address, err_correction_info, err_byte, err_sector, err_device,
> + err_correction_value;
Please use single line definitions for local variables:
u32 err_address, err_correction_info, err_byte, err_sector;
u32 err_device, err_correction_value;
Also, maybe you should use shorter names to avoid 80 chars wrapping as
much as possible.
>
> - if (irq_status & INTR_STATUS__ECC_ERR) {
> - /* read the ECC errors. we'll ignore them for now */
> - u32 err_address, err_correction_info, err_byte,
> - err_sector, err_device, err_correction_value;
> - denali_set_intr_modes(denali, false);
> -
> - do {
> - err_address = ioread32(denali->flash_reg +
> - ECC_ERROR_ADDRESS);
> - err_sector = ECC_SECTOR(err_address);
> - err_byte = ECC_BYTE(err_address);
> -
> - err_correction_info = ioread32(denali->flash_reg +
> - ERR_CORRECTION_INFO);
> - err_correction_value =
> + if (!(irq_status & INTR_STATUS__ECC_ERR))
> + goto out;
> +
> + /* read the ECC errors. we'll ignore them for now */
> + denali_set_intr_modes(denali, false);
> +
> + do {
> + err_address = ioread32(denali->flash_reg + ECC_ERROR_ADDRESS);
> + err_sector = ECC_SECTOR(err_address);
> + err_byte = ECC_BYTE(err_address);
> +
> + err_correction_info = ioread32(denali->flash_reg +
> +ERR_CORRECTION_INFO);
> + err_correction_value =
> ECC_CORRECTION_VALUE(err_correction_info);
> - err_device = ECC_ERR_DEVICE(err_correction_info);
> -
> - if (ECC_ERROR_CORRECTABLE(err_correction_info)) {
> - /*
> - * If err_byte is larger than ECC_SECTOR_SIZE,
> - * means error happened in OOB, so we ignore
> - * it. It's no need for us to correct it
> - * err_device is represented the NAND error
> - * bits are happened in if there are more
> - * than one NAND connected.
> - */
> - if (err_byte < ECC_SECTOR_SIZE) {
> - struct mtd_info *mtd =
> - nand_to_mtd(&denali->nand);
> - int offset;
> -
> - offset = (err_sector *
> - ECC_SECTOR_SIZE +
> - err_byte) *
> - denali->devnum +
> - err_device;
> - /* correct the ECC error */
> - buf[offset] ^= err_correction_value;
> - mtd->ecc_stats.corrected++;
> - bitflips++;
> - }
> - } else {
> - /*
> - * if the error is not correctable, need to
> - * look at the page to see if it is an erased
> - * page. if so, then it's not a real ECC error
> - */
> - check_erased_page = true;
> + err_device = ECC_ERR_DEVICE(err_correction_info);
> +
> + if (ECC_ERROR_CORRECTABLE(err_correction_info)) {
> + /*
> + * If err_byte is larger than ECC_SECTOR_SIZE, means
> error
> + * happened in OOB, so we ignore it. It's no need for
> + * us to correct it err_device is represented the NAND
> + * error bits are happened in if there a
Re: [PATCH v2 1/7] MFD: add bindings for stm32 general purpose timer driver
On 27/11/16 14:10, Jonathan Cameron wrote:
> On 24/11/16 15:14, Benjamin Gaignard wrote:
>> Add bindings information for stm32 general purpose timer
>>
>> version 2:
>> - rename stm32-mfd-timer to stm32-gptimer
>> - only keep one compatible string
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>> .../bindings/mfd/stm32-general-purpose-timer.txt | 43
>> ++
>> 1 file changed, 43 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>> b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>> new file mode 100644
>> index 000..2f10e67
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>> @@ -0,0 +1,43 @@
>> +STM32 general purpose timer driver
>> +
>> +Required parameters:
>> +- compatible: must be "st,stm32-gptimer"
>> +
>> +- reg: Physical base address and length of the
>> controller's
>> +registers.
>> +- clock-names: Set to "clk_int".
>> +- clocks: Phandle to the clock used by the timer module.
>> +For Clk properties, please refer to
>> ../clock/clock-bindings.txt
>> +
>> +Optional parameters:
>> +- resets: Phandle to the parent reset controller.
>> +See ..reset/st,stm32-rcc.txt
>> +
>> +Optional subnodes:
>> +- pwm: See ../pwm/pwm-stm32.txt
>> +- iiotimer: See ../iio/timer/stm32-iio-timer.txt
> Naming issue here. Can't mention IIO as that's a linux subsystem and all
> bindings must be independent of OS.
>
> Perhaps adc-trigger-timer?
>> +
>> +Example:
>> +gptimer1: gptimer1@4001 {
>> +compatible = "st,stm32-gptimer";
>> +reg = <0x4001 0x400>;
>> +clocks = <&rcc 0 160>;
>> +clock-names = "clk_int";
>> +
>> +pwm1@0 {
>> +compatible = "st,stm32-pwm";
>> +st,pwm-num-chan = <4>;
>> +st,breakinput;
>> +st,complementary;
>> +};
>> +
>> +iiotimer1@0 {
>> +compatible = "st,stm32-iio-timer";
> Again, avoid the use of iio in here (same issue you had with mfd in the
> previous
> version).
>> +interrupts = <27>;
>> +st,input-triggers-names = TIM5_TRGO,
> Docs for these should be introduced before they are used in an example.
> Same for the PWM ones above. Expand the detail fo the example as you add
> the other elements.
I've just dived into the datasheet for these timers.
http://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf
I think you need a binding that describes the capabilities of each of the timers
explicitly. Down to the level of whether there is a repetition counter or not.
Each should exists as a separate entity in device tree.
They then have an existence as timers separate to the description of what they
are used for.
Here the only way we are saying they exist is by their use which doesn't feel
right to me.
So I think you need to move back to what you had in the first place. The key
thing is that ever timer needs describing fully. They are different enough
that for example the datasheet doesn't even try to describe them in one section.
(it has 4 separate chapters covering different sets of these hardware blocks).
The naming isn't really based on index, we are talking different hardware
that the datasheet authors have decided not to give different names to!
If they'd called them
advanced timers
generic timers
basic timers
really basic timers meant for driving the DAC (6 and 7)
We'd all have been quite happy with different compatible strings giving away
what they can do.
What you have here is far too specific to what you are trying to do with them
right now.
These things are separately capable of timing capture (which is I guess where
the IIO device later comes in).
So my expectation is that we end up potentially instantiating:
1) An MFD to handle the shared elements of the timers.
2) Up to 12ish timers each with separate existence as a device in the driver
model
and in device tree.
(nasty corner cases here are using timers as perscalers for other timers - I'd
be
tempted to leave that for now)
Note that each of these devices has a different register set I think? Any shared
bits are handled via the mfd above (if we even need that MFD which I'm starting
to doubt looking at the datasheet).
3) Up to N pwms again with there own existence in the device model. These don't
do much other than wrap the timer and stick it in output mode.
4) Up to N iio triggers - this is basically using the timer as a periodic
interrupt
(though without the interrupt having vis
Re: [PATCH v2 6/7] IIO: add STM32 IIO timer driver
I delved into the datasheet after trying to figure this out, so I think I now sort of understand your intent, but please do answer the questions inline. On 24/11/16 15:14, Benjamin Gaignard wrote: > Timers IPs can be used to generate triggers for other IPs like > DAC, ADC or other timers. > Each trigger may result of timer internals signals like counter enable, > reset or edge, this configuration could be done through "master_mode" > device attribute. > > A timer device could be triggered by other timers, we use the trigger > name and is_stm32_iio_timer_trigger() function to distinguish them > and configure IP input switch. The presence of an IIO device in here was a suprise.. What is it actually for? I think this needs some examples of usage to make it clear what the aim is. I was basically expecting to see a driver instantiating one iio trigger per timer that can act as a trigger. Those would each have sampling frequency controls and basica enable / disable. I'm seeing something much more complex here so additional explanation is needed. > > Timer may also decide on which event (edge, level) they could > be activated by a trigger, this configuration is done by writing in > "slave_mode" device attribute. Really? Sounds like magic numbers in sysfs which is never a good idea. Please document those attributes / or break them up into elements that don't require magic numbers. > > Since triggers could also be used by DAC or ADC their names are defined > in include/dt-bindings/iio/timer/st,stm32-iio-timer.h so those IPs will be > able > to configure themselves in valid_trigger function > > Trigger have a "sampling_frequency" attribute which allow to configure > timer sampling frequency without using pwm interface > > version 2: > - keep only one compatible Hmm. I'm not sure I like this as such. We are actually dealing with lots of instances of a hardware block with only a small amount of shared infrastrcuture (which is classic mfd teritory). So to my mind we should have a separate device for each. > - use st,input-triggers-names and st,output-triggers-names > to know which triggers are accepted and/or create by the device I'm not following why we have this cascade setup? These are triggers, not devices in the IIO context. We need some detailed description of why you have it setup like this. This would include the ABI with examples of how you are using it. Basically I don't currently understand what you are doing :( Thanks, Jonathan > > Signed-off-by: Benjamin Gaignard > --- > drivers/iio/Kconfig| 2 +- > drivers/iio/Makefile | 1 + > drivers/iio/timer/Kconfig | 15 + > drivers/iio/timer/Makefile | 1 + > drivers/iio/timer/stm32-iio-timer.c| 448 > + > drivers/iio/trigger/Kconfig| 1 - > include/dt-bindings/iio/timer/st,stm32-iio-timer.h | 23 ++ > include/linux/iio/timer/stm32-iio-timers.h | 16 + > 8 files changed, 505 insertions(+), 2 deletions(-) > create mode 100644 drivers/iio/timer/Kconfig > create mode 100644 drivers/iio/timer/Makefile > create mode 100644 drivers/iio/timer/stm32-iio-timer.c > create mode 100644 include/dt-bindings/iio/timer/st,stm32-iio-timer.h > create mode 100644 include/linux/iio/timer/stm32-iio-timers.h > > diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig > index 6743b18..2de2a80 100644 > --- a/drivers/iio/Kconfig > +++ b/drivers/iio/Kconfig > @@ -90,5 +90,5 @@ source "drivers/iio/potentiometer/Kconfig" > source "drivers/iio/pressure/Kconfig" > source "drivers/iio/proximity/Kconfig" > source "drivers/iio/temperature/Kconfig" > - > +source "drivers/iio/timer/Kconfig" > endif # IIO > diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile > index 87e4c43..b797c08 100644 > --- a/drivers/iio/Makefile > +++ b/drivers/iio/Makefile > @@ -32,4 +32,5 @@ obj-y += potentiometer/ > obj-y += pressure/ > obj-y += proximity/ > obj-y += temperature/ > +obj-y += timer/ > obj-y += trigger/ > diff --git a/drivers/iio/timer/Kconfig b/drivers/iio/timer/Kconfig > new file mode 100644 > index 000..7a73bc6 > --- /dev/null > +++ b/drivers/iio/timer/Kconfig > @@ -0,0 +1,15 @@ > +# > +# Timers drivers > + > +menu "Timers" > + > +config IIO_STM32_TIMER > + tristate "stm32 iio timer" > + depends on ARCH_STM32 > + depends on OF > + select IIO_TRIGGERED_EVENT > + select MFD_STM32_GP_TIMER > + help > + Select this option to enable stm32 timers hardware IPs > + > +endmenu > diff --git a/drivers/iio/timer/Makefile b/drivers/iio/timer/Makefile > new file mode 100644 > index 000..a360c9f > --- /dev/null > +++ b/drivers/iio/timer/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_IIO_STM32_TIMER) += stm32-iio-timer.o > diff --git a/drivers/iio/timer/stm32-iio-timer.c > b/drivers/iio/timer/stm32-iio-timer.c > new file mode 100644 > index 000..35f2687 > -
Re: [PATCH 15/39] mtd: nand: denali: improve readability of handle_ecc()
On Sun, 27 Nov 2016 03:06:01 +0900
Masahiro Yamada wrote:
> This function is unreadable due to the deep nesting. Note this
> function does a job only when INTR_STATUS__ECC_ERR is set.
> So, if the flag is not set, let it bail-out.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.c | 119
> +++---
> 1 file changed, 59 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index a7dc692..b577560 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -908,69 +908,68 @@ static bool handle_ecc(struct denali_nand_info *denali,
> u8 *buf,
> {
> bool check_erased_page = false;
> unsigned int bitflips = 0;
> + u32 err_address, err_correction_info, err_byte, err_sector, err_device,
> + err_correction_value;
>
> - if (irq_status & INTR_STATUS__ECC_ERR) {
> - /* read the ECC errors. we'll ignore them for now */
> - u32 err_address, err_correction_info, err_byte,
> - err_sector, err_device, err_correction_value;
> - denali_set_intr_modes(denali, false);
> -
> - do {
> - err_address = ioread32(denali->flash_reg +
> - ECC_ERROR_ADDRESS);
> - err_sector = ECC_SECTOR(err_address);
> - err_byte = ECC_BYTE(err_address);
> -
> - err_correction_info = ioread32(denali->flash_reg +
> - ERR_CORRECTION_INFO);
> - err_correction_value =
> + if (!(irq_status & INTR_STATUS__ECC_ERR))
> + goto out;
> +
> + /* read the ECC errors. we'll ignore them for now */
> + denali_set_intr_modes(denali, false);
> +
> + do {
> + err_address = ioread32(denali->flash_reg + ECC_ERROR_ADDRESS);
> + err_sector = ECC_SECTOR(err_address);
> + err_byte = ECC_BYTE(err_address);
> +
> + err_correction_info = ioread32(denali->flash_reg +
> +ERR_CORRECTION_INFO);
> + err_correction_value =
> ECC_CORRECTION_VALUE(err_correction_info);
> - err_device = ECC_ERR_DEVICE(err_correction_info);
> -
> - if (ECC_ERROR_CORRECTABLE(err_correction_info)) {
> - /*
> - * If err_byte is larger than ECC_SECTOR_SIZE,
> - * means error happened in OOB, so we ignore
> - * it. It's no need for us to correct it
> - * err_device is represented the NAND error
> - * bits are happened in if there are more
> - * than one NAND connected.
> - */
> - if (err_byte < ECC_SECTOR_SIZE) {
> - struct mtd_info *mtd =
> - nand_to_mtd(&denali->nand);
> - int offset;
> -
> - offset = (err_sector *
> - ECC_SECTOR_SIZE +
> - err_byte) *
> - denali->devnum +
> - err_device;
> - /* correct the ECC error */
> - buf[offset] ^= err_correction_value;
> - mtd->ecc_stats.corrected++;
> - bitflips++;
> - }
> - } else {
> - /*
> - * if the error is not correctable, need to
> - * look at the page to see if it is an erased
> - * page. if so, then it's not a real ECC error
> - */
> - check_erased_page = true;
> + err_device = ECC_ERR_DEVICE(err_correction_info);
> +
> + if (ECC_ERROR_CORRECTABLE(err_correction_info)) {
> + /*
> + * If err_byte is larger than ECC_SECTOR_SIZE, means
> error
> + * happened in OOB, so we ignore it. It's no need for
> + * us to correct it err_device is represented the NAND
> + * error bits are happened in if there are more than
> + * one NAND connected.
> + */
> + if (err_byte < ECC_SECTOR_SIZE) {
> + struct mtd_info *mtd =
> + nand_to_mtd(&denali->n
Re: [PATCH v2 5/7] IIO: add bindings for stm32 IIO timer driver
2016-11-27 15:25 GMT+01:00 Jonathan Cameron :
> On 24/11/16 15:14, Benjamin Gaignard wrote:
>> Define bindings for stm32 IIO timer
>>
>> version 2:
>> - only keep one compatible
>> - add DT parameters to set lists of the triggers:
>> one list describe the triggers created by the device
>> another one give the triggers accepted by the device
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>> .../bindings/iio/timer/stm32-iio-timer.txt | 41
>> ++
>> 1 file changed, 41 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>> b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>> new file mode 100644
>> index 000..840b417
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>> @@ -0,0 +1,41 @@
>> +timer IIO trigger bindings for STM32
>> +
>> +Must be a sub-node of STM32 general purpose timer driver
> Add a cross reference...
I will add it in v3
>> +
>> +Required parameters:
>> +- compatible:must be "st,stm32-iio-timer"
> st,stm32-adc-timer or something like that.
I would prefer use st,stm32-timer-trigger because triggers can be used
for multiple other devices (dac, adc, timers)
>> +- interrupts:Interrupt for this device
>> + See ../interrupt-controller/st,stm32-exti.txt
>> +
>> +Optional parameters:
>> +- st,input-triggers-names: List of the possible input triggers for
>> + the device
>> +- st,output-triggers-names: List of the possible output triggers for
>> + the device
> What are input / output triggers?
each hardware block can be the source of triggers (output triggers) or customer
of some other trigger (input triggers).That what I have tried to
describe in those two
parameters
>> +
>> +Possible triggers are defined in
>> include/dt-bindings/iio/timer/st,stm32-iio-timer.h
>> +
>> +Example:
>> + gptimer1: gptimer1@4001 {
>> + compatible = "st,stm32-gptimer";
>> + reg = <0x4001 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm1@0 {
>> + compatible = "st,stm32-pwm";
>> + st,pwm-num-chan = <4>;
>> + st,breakinput;
>> + st,complementary;
>> + };
>> +
>> + iiotimer1@0 {
>> + compatible = "st,stm32-iio-timer";
>> + interrupts = <27>;
>> + st,input-triggers-names = TIM5_TRGO,
>> + TIM2_TRGO,
>> + TIM4_TRGO,
>> + TIM3_TRGO;
>> + st,output-triggers-names = TIM1_TRGO;
>> + };
>> + };
>>
>
Re: [PATCH v8 3/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature
Hi Jonathan,
> Am 27.11.2016 um 12:02 schrieb Jonathan Cameron :
>
> On 24/11/16 18:05, H. Nikolaus Schaller wrote:
>>
>>> Am 24.11.2016 um 18:38 schrieb Jonathan Cameron
>>> :
>>>
>>>
>>>
>>> On 22 November 2016 14:02:30 GMT+00:00, "H. Nikolaus Schaller"
>>> wrote:
The tsc2007 chip not only has a resistive touch screen controller but
also an external AUX adc imput which can be used for an ambient
light sensor, battery voltage monitoring or any general purpose.
Additionally it can measure the chip temperature.
This extension provides an iio interface for these adc channels.
Since it is not wasting much resources and is very straightforward,
we simply provide all other adc channels as optional iio interfaces
as weel. This can be used for debugging or special applications.
This patch also splits the tsc2007 driver in several source files:
tsc2007.h -- constants, structs and stubs
tsc2007_core.c -- functional parts of the original driver
tsc2007_iio.c -- the optional iio stuff
Makefile magic allows to conditionally link the iio stuff
if CONFIG_IIO=y or =m in a way that it works with
CONFIG_TOUCHSCREEN_TSC2007=m.
Signed-off-by: H. Nikolaus Schaller
Reviewed-by: Jonathan Cameron
---
drivers/input/touchscreen/Makefile | 7 +
drivers/input/touchscreen/tsc2007.h| 116
.../touchscreen/{tsc2007.c => tsc2007_core.c} | 95 +++--
drivers/input/touchscreen/tsc2007_iio.c| 150
+
4 files changed, 294 insertions(+), 74 deletions(-)
create mode 100644 drivers/input/touchscreen/tsc2007.h
rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 81b8645..3be0d19 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -80,6 +80,13 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO) += tsc40.o
obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
obj-$(CONFIG_TOUCHSCREEN_TSC2004) += tsc2004.o
obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o
+tsc2007-y := tsc2007_core.o
+ifeq ($(CONFIG_IIO),y)
+tsc2007-y += tsc2007_iio.o
+endif
+ifeq ($(CONFIG_IIO),m)
+tsc2007-y += tsc2007_iio.o
>>>
>>> Not tsc2007-m ?
>>>
>>> I don't follow how this works!
>>
>> I guess tsc2007-y is an internal collector variable name
>> for multiple .o components. Sort of a "library" object.
>>
>> While
>>
>> obj-y += tsc2007.o adds it to the kernel
>> obj-m += tsc2007.o adds it to the modules
>>
>> I am not sure if my explanation is correct but it appears
>> to work that way.
>>
>> Anyways what shall we do? If CONFIG_TOUCHSCREEN_TSC2007=y
>> and IIO=m we have a problem that we need dynamic binding.
> Yes, we just need to block that particular combination. Only build in the IIO
> support
> if it is also built in. That's way I thought we'd want to add it tsc2007-m
> which would
> only be used if tsc2007 as a whole was built as a module.
Yes, that is what one could expect.
> Otherwise it would be ignored (I think!)
>
> I'm not seeing this structure anywhere else in kernel
It is also not described in that way:
http://lxr.free-electrons.com/source/Documentation/kbuild/modules.txt#L146
it only talks about obj-m and -y but not -m
> - hence cc'd Yann and the Kbuild list
> to see if they can offer some advices.
Thanks!
BTW, the other tsc2007 and ads7846 patches could already be merged (if there
are no more changes needed) since this one only depends on the result of
applying
all others before.
>
> As a quick summary, we are looking to add IIO support to this driver in the
> following circumstances.
>
> IIO and this driver are modules. (ideally handling the dependencies nicely)
> IIO and this driver are both built in.
>
> Problem case is driver built in and IIO as a module.
>
> Jonathan
>>
+endif
obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o
obj-$(CONFIG_TOUCHSCREEN_UCB1400) += ucb1400_ts.o
obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001) += wacom_w8001.o
diff --git a/drivers/input/touchscreen/tsc2007.h
b/drivers/input/touchscreen/tsc2007.h
new file mode 100644
index 000..c25932f
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2007.h
@@ -0,0 +1,116 @@
+/*
+ * Copyright (c) 2008 MtekVision Co., Ltd.
+ *Kwangwoo Lee
+ *
+ * Using code from:
+ * - ads7846.c
+ *Copyright (c) 2005 David Brownell
+ *Copyright (c) 2006 Nokia Corporation
+ * - corgi_ts.c
+ *Copyright (C) 2004-2005 Richard Purdi
Re: [PATCH v2 5/7] IIO: add bindings for stm32 IIO timer driver
On 27/11/16 15:45, Benjamin Gaignard wrote:
> 2016-11-27 15:25 GMT+01:00 Jonathan Cameron :
>> On 24/11/16 15:14, Benjamin Gaignard wrote:
>>> Define bindings for stm32 IIO timer
>>>
>>> version 2:
>>> - only keep one compatible
>>> - add DT parameters to set lists of the triggers:
>>> one list describe the triggers created by the device
>>> another one give the triggers accepted by the device
>>>
>>> Signed-off-by: Benjamin Gaignard
>>> ---
>>> .../bindings/iio/timer/stm32-iio-timer.txt | 41
>>> ++
>>> 1 file changed, 41 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>>> b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>>> new file mode 100644
>>> index 000..840b417
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
>>> @@ -0,0 +1,41 @@
>>> +timer IIO trigger bindings for STM32
>>> +
>>> +Must be a sub-node of STM32 general purpose timer driver
>> Add a cross reference...
>
> I will add it in v3
>
>>> +
>>> +Required parameters:
>>> +- compatible:must be "st,stm32-iio-timer"
>> st,stm32-adc-timer or something like that.
>
> I would prefer use st,stm32-timer-trigger because triggers can be used
> for multiple other devices (dac, adc, timers)
>
>>> +- interrupts:Interrupt for this device
>>> + See ../interrupt-controller/st,stm32-exti.txt
>>> +
>>> +Optional parameters:
>>> +- st,input-triggers-names: List of the possible input triggers for
>>> + the device
>>> +- st,output-triggers-names: List of the possible output triggers for
>>> + the device
>> What are input / output triggers?
>
> each hardware block can be the source of triggers (output triggers) or
> customer
> of some other trigger (input triggers).That what I have tried to
> describe in those two
> parameters
So this is really about using one timer as a prescaler for another?
I'd be tempted in the first instance to drop that functionality and just
describe the ones that drive the device sampling.
It's complex to describe and there is enough complexity in here already
to keep things busy for a while!
>
>>> +
>>> +Possible triggers are defined in
>>> include/dt-bindings/iio/timer/st,stm32-iio-timer.h
>>> +
>>> +Example:
>>> + gptimer1: gptimer1@4001 {
>>> + compatible = "st,stm32-gptimer";
>>> + reg = <0x4001 0x400>;
>>> + clocks = <&rcc 0 160>;
>>> + clock-names = "clk_int";
>>> +
>>> + pwm1@0 {
>>> + compatible = "st,stm32-pwm";
>>> + st,pwm-num-chan = <4>;
>>> + st,breakinput;
>>> + st,complementary;
>>> + };
>>> +
>>> + iiotimer1@0 {
>>> + compatible = "st,stm32-iio-timer";
>>> + interrupts = <27>;
>>> + st,input-triggers-names = TIM5_TRGO,
>>> + TIM2_TRGO,
>>> + TIM4_TRGO,
>>> + TIM3_TRGO;
>>> + st,output-triggers-names = TIM1_TRGO;
>>> + };
>>> + };
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [HMM v13 00/18] HMM (Heterogeneous Memory Management) v13
On 11/25/2016 6:16 PM, Jerome Glisse wrote: > Yes this is something i have work on with NVidia, idea is that you will > see the hmm_pfn_t with the device flag set you can then retrive the struct > device from it. Issue is now to figure out how from that you can know that > this is a device with which you can interact. I would like a common and > device agnostic solution but i think as first step you will need to rely > on some back channel communication. Maybe this can be done with the same DMA-API changes you mention below. Given two device structs (the peer doing the mapping and the device that provided the pages) and some (unaddressable) ZONE_DEVICE page structs, ask the DMA-API to provide bus addresses for that p2p transaction. > Once you have setup a peer mapping to the GPU memory its lifetime will be > tie with CPU page table content ie if the CPU page table is updated either > to remove the page (because of munmap/truncate ...) or because the page > is migrated to some other place. In both case the device using the peer > mapping must stop using it and refault to update its page table with the > new page where the data is. Sounds good. > Issue to implement the above lie in the order in which mmu_notifier call- > back are call. We want to tear down the peer mapping only once we know > that any device using it is gone. If all device involve use the HMM mirror > API then this can be solve easily. Otherwise it will need some change to > mmu_notifier. I'm not sure I understand how p2p would work this way. If the device that provides the memory is using HMM for migration it marks the CPU page tables with the special swap entry. Another device that is not using HMM mirroring won't be able to translate this into a pfn, even if it uses mmu notifiers. > Note that all of the above would rely on change to DMA-API to allow to > IOMMAP (through iommu) PCI bar address into a device IOMMU context. But > this is an orthogonal issue. Even without an IOMMU, I think the DMA-API is a good place to tell whether p2p is at all possible, or whether it is a good idea in terms of performance.
Re: [PATCH 17/39] mtd: nand: denali: support HW_ECC_FIXUP capability
On Sun, 27 Nov 2016 03:06:03 +0900
Masahiro Yamada wrote:
> Some old versions of the Denali IP (perhaps used only for Intel?)
> detects ECC errors and provides correct data via a register, but
> does not touch the transferred data. So, the software must fixup
> the data in the buffer according to the provided ECC correction
> information.
>
> Newer versions perform ECC correction before transferring the data.
> No more software intervention is needed. The ECC_ERROR_ADDRESS and
> ECC_CORRECTION_INFO registers were deprecated. Instead, the number
> of corrected bit-flips can be read from the ECC_COR_INFO register.
> When an uncorrectable ECC error happens, a status flag is set to the
> INTR_STATUS and ECC_COR_INFO registers.
>
> As is often the case with this IP, the register view of INTR_STATUS
> had broken compatibility.
>
> For older versions (SW ECC fixup):
> bit 0: ECC_TRANSACTION_DONE
> bit 1: ECC_ERR
>
> For newer versions (HW ECC fixup):
> bit 0: ECC_UNCOR_ERR
> bit 1: Reserved
>
> Due to this difference, the irq_mask must be fixed too. The comment
> block in the denali_sw_ecc_fixup() has been moved to the common part
> because the comment applies to both cases.
>
> The U-Boot port of this driver already supports the HW ECC fixup. I
> borrowed the comment "Some versions of ..." in denali.h from U-Boot.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.c | 44 ++--
> drivers/mtd/nand/denali.h | 14 ++
> 2 files changed, 48 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 271b41a..c101e7f 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -894,6 +894,25 @@ static bool is_erased(u8 *buf, int len)
> return false;
> return true;
> }
> +
> +static bool denali_hw_ecc_fixup(struct denali_nand_info *denali,
> + unsigned int *max_bitflips)
> +{
> + int bank = denali->flash_bank;
> + u32 ecc_cor;
> +
> + ecc_cor = ioread32(denali->flash_reg + ECC_COR_INFO(bank));
> + ecc_cor >>= ECC_COR_INFO_SHIFT(bank);
> +
> + if (ecc_cor & ECC_COR_INFO__UNCOR_ERR) {
> + *max_bitflips = 0;
> + return true;
> + }
> +
> + *max_bitflips = ecc_cor & ECC_COR_INFO__MAX_ERRORS;
> + return false;
> +}
> +
> #define ECC_SECTOR_SIZE 512
>
> #define ECC_SECTOR(x)(((x) & ECC_ERROR_ADDRESS__SECTOR_NR) >> 12)
> @@ -949,11 +968,6 @@ static bool denali_sw_ecc_fixup(struct denali_nand_info
> *denali, u8 *buf,
> bitflips++;
> }
> } else {
> - /*
> - * if the error is not correctable, need to look at the
> - * page to see if it is an erased page. if so, then
> - * it's not a real ECC error
> - */
> check_erased_page = true;
> }
> } while (!ECC_LAST_ERR(err_correction_info));
> @@ -1109,12 +1123,12 @@ static int denali_read_page(struct mtd_info *mtd,
> struct nand_chip *chip,
> {
> unsigned int max_bitflips;
> struct denali_nand_info *denali = mtd_to_denali(mtd);
> -
> dma_addr_t addr = denali->buf.dma_buf;
> size_t size = mtd->writesize + mtd->oobsize;
> -
> u32 irq_status;
> - u32 irq_mask = INTR_STATUS__ECC_TRANSACTION_DONE | INTR_STATUS__ECC_ERR;
> + u32 irq_mask = denali->caps & DENALI_CAPS_HW_ECC_FIXUP ?
> + INTR_STATUS__DMA_CMD_COMP | INTR_STATUS__ECC_UNCOR_ERR :
> + INTR_STATUS__ECC_TRANSACTION_DONE | INTR_STATUS__ECC_ERR;
> bool check_erased_page = false;
>
> if (page != denali->page) {
> @@ -1139,11 +1153,21 @@ static int denali_read_page(struct mtd_info *mtd,
> struct nand_chip *chip,
>
> memcpy(buf, denali->buf.buf, mtd->writesize);
>
> - check_erased_page = denali_sw_ecc_fixup(denali, buf, irq_status,
> - &max_bitflips);
> + if (denali->caps & DENALI_CAPS_HW_ECC_FIXUP)
> + check_erased_page = denali_hw_ecc_fixup(denali, &max_bitflips);
> + else
> + check_erased_page = denali_sw_ecc_fixup(denali, buf, irq_status,
> + &max_bitflips);
Okay, so you currently have two ways of handling ECC errors. What if a
new revision introduces yet another way to do it?
How about making denali_caps a structure where you have one (or several)
function pointers to implement operations differently depending on the
IP revision?
struct denali_caps {
u32 feature_flags; /* If needed. */
bool (*handle_ecc)(...);
...
};
> +
> denali_enable_dma(denali, false);
>
> if (check_erased_page) {
> + /*
> + * If the error is not correctable, need to look at the page to
Re: [PATCH 18/39] mtd: nand: denali: move denali_read_page_raw() above denali_read_page()
On Sun, 27 Nov 2016 03:06:04 +0900
Masahiro Yamada wrote:
> This will be needed in the next commit to call denali_read_page_raw()
> from denali_read_page().
Please squash this change into patch 19. It's clearly useless to
dissociate them.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.c | 76
> +++
> 1 file changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index c101e7f..f035dac 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1118,6 +1118,44 @@ static int denali_read_oob(struct mtd_info *mtd,
> struct nand_chip *chip,
> return 0;
> }
>
> +static int denali_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
> + u8 *buf, int oob_required, int page)
> +{
> + struct denali_nand_info *denali = mtd_to_denali(mtd);
> + dma_addr_t addr = denali->buf.dma_buf;
> + size_t size = mtd->writesize + mtd->oobsize;
> + u32 irq_mask = INTR_STATUS__DMA_CMD_COMP;
> +
> + if (page != denali->page) {
> + dev_err(denali->dev,
> + "IN %s: page %d is not equal to denali->page %d",
> + __func__, page, denali->page);
> + BUG();
> + }
> +
> + setup_ecc_for_xfer(denali, false, oob_required ? true : false);
> + denali_enable_dma(denali, true);
> +
> + dma_sync_single_for_device(denali->dev, addr, size, DMA_FROM_DEVICE);
> +
> + clear_interrupts(denali);
> + denali_setup_dma(denali, DENALI_READ);
> +
> + /* wait for operation to complete */
> + wait_for_irq(denali, irq_mask);
> +
> + dma_sync_single_for_cpu(denali->dev, addr, size, DMA_FROM_DEVICE);
> +
> + denali_enable_dma(denali, false);
> +
> + memcpy(buf, denali->buf.buf, mtd->writesize);
> + if (oob_required)
> + memcpy(chip->oob_poi, denali->buf.buf + mtd->writesize,
> +mtd->oobsize);
> +
> + return 0;
> +}
> +
> static int denali_read_page(struct mtd_info *mtd, struct nand_chip *chip,
> u8 *buf, int oob_required, int page)
> {
> @@ -1182,44 +1220,6 @@ static int denali_read_page(struct mtd_info *mtd,
> struct nand_chip *chip,
> return max_bitflips;
> }
>
> -static int denali_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
> - u8 *buf, int oob_required, int page)
> -{
> - struct denali_nand_info *denali = mtd_to_denali(mtd);
> - dma_addr_t addr = denali->buf.dma_buf;
> - size_t size = mtd->writesize + mtd->oobsize;
> - u32 irq_mask = INTR_STATUS__DMA_CMD_COMP;
> -
> - if (page != denali->page) {
> - dev_err(denali->dev,
> - "IN %s: page %d is not equal to denali->page %d",
> - __func__, page, denali->page);
> - BUG();
> - }
> -
> - setup_ecc_for_xfer(denali, false, oob_required ? true : false);
> - denali_enable_dma(denali, true);
> -
> - dma_sync_single_for_device(denali->dev, addr, size, DMA_FROM_DEVICE);
> -
> - clear_interrupts(denali);
> - denali_setup_dma(denali, DENALI_READ);
> -
> - /* wait for operation to complete */
> - wait_for_irq(denali, irq_mask);
> -
> - dma_sync_single_for_cpu(denali->dev, addr, size, DMA_FROM_DEVICE);
> -
> - denali_enable_dma(denali, false);
> -
> - memcpy(buf, denali->buf.buf, mtd->writesize);
> - if (oob_required)
> - memcpy(chip->oob_poi, denali->buf.buf + mtd->writesize,
> -mtd->oobsize);
> -
> - return 0;
> -}
> -
> static u8 denali_read_byte(struct mtd_info *mtd)
> {
> struct denali_nand_info *denali = mtd_to_denali(mtd);
Re: [PATCH 19/39] mtd: nand: denali: perform erased check against raw transferred page
On Sun, 27 Nov 2016 03:06:05 +0900
Masahiro Yamada wrote:
> The erased page check must be done against the raw transferred data.
> The current first call of is_erase() is against the data after ECC
> correction. I saw cases where not all of the data in the page are
> 0xFF after they are manipulated by the ECC correction engine.
Hm, that's surprising. Usually ECC engines leaves data unchanged when
uncorrectable errors are detected. Do you have examples where this
happens? How did you trigger this case?
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index f035dac..ae44c01 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1168,6 +1168,7 @@ static int denali_read_page(struct mtd_info *mtd,
> struct nand_chip *chip,
> INTR_STATUS__DMA_CMD_COMP | INTR_STATUS__ECC_UNCOR_ERR :
> INTR_STATUS__ECC_TRANSACTION_DONE | INTR_STATUS__ECC_ERR;
> bool check_erased_page = false;
> + int ret;
>
> if (page != denali->page) {
> dev_err(denali->dev,
> @@ -1206,7 +1207,9 @@ static int denali_read_page(struct mtd_info *mtd,
> struct nand_chip *chip,
>* error.
>*/
>
> - read_oob_data(mtd, chip->oob_poi, denali->page);
> + ret = denali_read_page_raw(mtd, chip, buf, 1, denali->page);
> + if (ret < 0)
> + return ret;
>
> /* check ECC failures that may have occurred on erased pages */
> if (!is_erased(buf, mtd->writesize) ||
Re: [PATCH 20/39] mtd: nand: denali_dt: enable HW_ECC_FIXUP capability for DT platform
On Sun, 27 Nov 2016 03:06:06 +0900 Masahiro Yamada wrote: > The denali_dt.c was split out by Altera for the SOCFPGA port. The > Denali IP on SOCFPGA incorporates the hardware ECC fixup feature. > Newer versions are very likely to support it. So, it should be OK > to set DENALI_CAPS_HW_ECC_FIXUP for all DT platforms. Seems like a bad idea. What's the problem with setting this flag in the data->caps definition of each revision? > > Signed-off-by: Masahiro Yamada > --- > > drivers/mtd/nand/denali_dt.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c > index 293ddb8..9dcd203 100644 > --- a/drivers/mtd/nand/denali_dt.c > +++ b/drivers/mtd/nand/denali_dt.c > @@ -59,6 +59,8 @@ static int denali_dt_probe(struct platform_device *ofdev) > if (data) > denali->caps = data->caps; > > + denali->caps |= DENALI_CAPS_HW_ECC_FIXUP; > + > denali->platform = DT; > denali->dev = &ofdev->dev; > denali->irq = platform_get_irq(ofdev, 0);
Re: [PATCH] Fix objtool with clang
On Sat, Nov 26, 2016 at 05:20:35PM -0500, Peter Foley wrote: > Clang doesn't support multiple arguments being passed to -Wp, so split > them. > > Fixes this error: > HOSTCC tools/objtool/fixdep.o > cat: tools/objtool/.fixdep.o.d: No such file or directory > > Signed-off-by: Peter Foley > --- > tools/build/Build.include | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/tools/build/Build.include b/tools/build/Build.include > index 1dcb95e76f70..83c7be908009 100644 > --- a/tools/build/Build.include > +++ b/tools/build/Build.include > @@ -89,10 +89,10 @@ if_changed = $(if $(strip $(any-prereq) $(arg-check)), > \ > # - per target C flags > # - per object C flags > # - BUILD_STR macro to allow '-D"$(variable)"' constructs > -c_flags = -Wp,-MD,$(depfile),-MT,$@ $(CFLAGS) -D"BUILD_STR(s)=\#s" > $(CFLAGS_$(basetarget).o) $(CFLAGS_$(obj)) > -cxx_flags = -Wp,-MD,$(depfile),-MT,$@ $(CXXFLAGS) -D"BUILD_STR(s)=\#s" > $(CXXFLAGS_$(basetarget).o) $(CXXFLAGS_$(obj)) > +c_flags = -Wp,-MD,$(depfile) -Wp,-MT,$@ $(CFLAGS) -D"BUILD_STR(s)=\#s" > $(CFLAGS_$(basetarget).o) $(CFLAGS_$(obj)) > +cxx_flags = -Wp,-MD,$(depfile) -Wp,-MT,$@ $(CXXFLAGS) -D"BUILD_STR(s)=\#s" > $(CXXFLAGS_$(basetarget).o) $(CXXFLAGS_$(obj)) could you please rebase this on Arnaldo's latest perf/core branch? (git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git) thanks, jirka
Re: [PATCH 21/39] mtd: nand: denali: support 64bit capable DMA engine
On Sun, 27 Nov 2016 03:06:07 +0900
Masahiro Yamada wrote:
> The current driver only supports the DMA engine up to 32 bit
> physical address, but there also exists 64 bit capable DMA engine
> for this IP.
>
> The data DMA setup sequence is completely different, so I added the
> 64 bit DMA code as a new function denali_setup_dma64(). The 32 bit
> one has been renamed to denali_setup_dma32().
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.c | 39 +++
> drivers/mtd/nand/denali.h | 1 +
> 2 files changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index ae44c01..752ad98 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -995,8 +995,30 @@ static void denali_enable_dma(struct denali_nand_info
> *denali, bool en)
> ioread32(denali->flash_reg + DMA_ENABLE);
> }
>
> -/* setups the HW to perform the data DMA */
> -static void denali_setup_dma(struct denali_nand_info *denali, int op)
> +static void denali_setup_dma64(struct denali_nand_info *denali, int op)
> +{
> + u32 mode;
> + const int page_count = 1;
> + u64 addr = denali->buf.dma_buf;
> +
> + mode = MODE_10 | BANK(denali->flash_bank) | denali->page;
> +
> + /* DMA is a three step process */
> +
> + /*
> + * 1. setup transfer type, interrupt when complete,
> + *burst len = 64 bytes, the number of pages
> + */
> + index_addr(denali, mode, 0x01002000 | (64 << 16) | op | page_count);
> +
> + /* 2. set memory low address */
> + index_addr(denali, mode, addr);
> +
> + /* 3. set memory high address */
> + index_addr(denali, mode, addr >> 32);
> +}
> +
> +static void denali_setup_dma32(struct denali_nand_info *denali, int op)
> {
> u32 mode;
> const int page_count = 1;
> @@ -1019,6 +1041,14 @@ static void denali_setup_dma(struct denali_nand_info
> *denali, int op)
> index_addr(denali, mode | 0x14000, 0x2400);
> }
>
> +static void denali_setup_dma(struct denali_nand_info *denali, int op)
> +{
> + if (denali->caps & DENALI_CAPS_DMA_64BIT)
> + denali_setup_dma64(denali, op);
> + else
> + denali_setup_dma32(denali, op);
> +}
> +
If you follow my suggestions of definition function pointers, you'll
just have to add a function pointer to the denali_caps struct:
void (*setup_dma)(struct denali_nand_info *denali, int op);
> /*
> * writes a page. user specifies type, and this function handles the
> * configuration details.
> @@ -1495,8 +1525,9 @@ int denali_init(struct denali_nand_info *denali)
> goto failed_req_irq;
> }
>
> - /* Is 32-bit DMA supported? */
> - ret = dma_set_mask(denali->dev, DMA_BIT_MASK(32));
> + ret = dma_set_mask(denali->dev,
> +DMA_BIT_MASK(denali->caps & DENALI_CAPS_DMA_64BIT ?
> + 64 : 32));
> if (ret) {
> dev_err(denali->dev, "no usable DMA configuration\n");
> goto failed_req_irq;
> diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
> index beadc8a..9bdf037 100644
> --- a/drivers/mtd/nand/denali.h
> +++ b/drivers/mtd/nand/denali.h
> @@ -435,6 +435,7 @@ struct denali_nand_info {
> u32 max_banks;
> unsigned int caps;
> #define DENALI_CAPS_HW_ECC_FIXUP BIT(0)
> +#define DENALI_CAPS_DMA_64BITBIT(1)
> };
>
> extern int denali_init(struct denali_nand_info *denali);
Re: [PATCH 28/39] mtd: nand: denali: move multi NAND fixup code to a helper function
On Sun, 27 Nov 2016 03:06:14 +0900
Masahiro Yamada wrote:
> Collect multi NAND fixups into a helper function instead of
> scattering them in denali_init().
Can you tell me more about this multi-NAND feature?
The core is already able to detect multi-die NAND chips in a generic
way, but I fear this is something else, like "put two 8-bits chips on a
16bits bus to emulate a single 16bits chip".
If that's a case, and this feature is actually used, then it's a bad
idea IMHO.
For example, how do you handle the case where one block is bad on a
chip but not on the other? And I fear this is not the only problem
with this approach :-/.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.c | 51
> ---
> 1 file changed, 31 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 60b0858..54dcd83 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1472,6 +1472,34 @@ static void denali_drv_init(struct denali_nand_info
> *denali)
> denali->irq_status = 0;
> }
>
> +static void denali_multidev_fixup(struct denali_nand_info *denali)
> +{
> + struct nand_chip *chip = &denali->nand;
> + struct mtd_info *mtd = nand_to_mtd(chip);
> +
> + /*
> + * Support for multi NAND:
> + * MTD knows nothing about multi NAND, so we should tell it
> + * the real pagesize and anything necessary
> + */
> + denali->devnum = ioread32(denali->flash_reg + DEVICES_CONNECTED);
> +
> + mtd->size <<= denali->devnum - 1;
> + mtd->erasesize <<= denali->devnum - 1;
> + mtd->writesize <<= denali->devnum - 1;
> + mtd->oobsize <<= denali->devnum - 1;
> + chip->chipsize <<= denali->devnum - 1;
> + chip->page_shift += denali->devnum - 1;
> + chip->phys_erase_shift += denali->devnum - 1;
> + chip->bbt_erase_shift += denali->devnum - 1;
> + chip->chip_shift += denali->devnum - 1;
> + chip->pagemask <<= denali->devnum - 1;
> + chip->ecc.size *= denali->devnum;
> + chip->ecc.bytes *= denali->devnum;
> + chip->ecc.strength *= denali->devnum;
> + denali->bbtskipbytes *= denali->devnum;
> +}
> +
> int denali_init(struct denali_nand_info *denali)
> {
> struct nand_chip *chip = &denali->nand;
> @@ -1553,23 +1581,6 @@ int denali_init(struct denali_nand_info *denali)
> goto failed_req_irq;
> }
>
> - /*
> - * support for multi nand
> - * MTD known nothing about multi nand, so we should tell it
> - * the real pagesize and anything necessery
> - */
> - denali->devnum = ioread32(denali->flash_reg + DEVICES_CONNECTED);
> - chip->chipsize <<= denali->devnum - 1;
> - chip->page_shift += denali->devnum - 1;
> - chip->pagemask = (chip->chipsize >> chip->page_shift) - 1;
> - chip->bbt_erase_shift += denali->devnum - 1;
> - chip->phys_erase_shift = chip->bbt_erase_shift;
> - chip->chip_shift += denali->devnum - 1;
> - mtd->writesize <<= denali->devnum - 1;
> - mtd->oobsize <<= denali->devnum - 1;
> - mtd->erasesize <<= denali->devnum - 1;
> - mtd->size = chip->numchips * chip->chipsize;
> - denali->bbtskipbytes *= denali->devnum;
>
> /*
>* second stage of the NAND scan
> @@ -1614,11 +1625,9 @@ int denali_init(struct denali_nand_info *denali)
> }
>
> mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
> - chip->ecc.bytes *= denali->devnum;
> - chip->ecc.strength *= denali->devnum;
>
> /* override the default read operations */
> - chip->ecc.size = ECC_SECTOR_SIZE * denali->devnum;
> + chip->ecc.size = ECC_SECTOR_SIZE;
> chip->ecc.read_page = denali_read_page;
> chip->ecc.read_page_raw = denali_read_page_raw;
> chip->ecc.write_page = denali_write_page;
> @@ -1627,6 +1636,8 @@ int denali_init(struct denali_nand_info *denali)
> chip->ecc.write_oob = denali_write_oob;
> chip->erase = denali_erase;
>
> + denali_multidev_fixup(denali);
> +
> ret = nand_scan_tail(mtd);
> if (ret)
> goto failed_req_irq;
Re: [PATCH 38/39] mtd: nand: denali: remove Toshiba, Hynix specific fixup code
On Sun, 27 Nov 2016 03:06:24 +0900
Masahiro Yamada wrote:
> The Denali IP can automatically detect device parameters such as
> page size, device width, etc. and this driver currently relies on it.
> However, this hardware function is problematic.
>
> [1] Due to a hardware bug, various misdetected cases are known.
> That is why get_toshiba_nand_para(), get_hynix_nand_para() exist
> to fix the misdetected parameters. It is not realistic to add a
> new NAND device to the *black list* every time we are hit by a
> misdetected case. We would never be able to guarantee that all
> the cases are covered.
>
> [2] Because this feature is unreliable, it is disabled on some
> platforms.
>
> The nand_scan_ident() sets device parameters such as mtd->writesize,
> mtd->erasesize, etc. in a more tested way. We should not set the
> hardware registers in a different, unreliable way. Instead, set
> the parameters from nand_scan_ident() back to the registers.
>
Thanks a lot for fixing that.
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/denali.c | 39 ++-
> 1 file changed, 6 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index df174ca..1aa19ec 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -338,35 +338,6 @@ static void get_samsung_nand_para(struct
> denali_nand_info *denali, u8 device_id)
> }
> }
>
> -static void get_toshiba_nand_para(struct denali_nand_info *denali)
> -{
> - /*
> - * Workaround to fix a controller bug which reports a wrong
> - * spare area size for some kind of Toshiba NAND device
> - */
> - if ((ioread32(denali->flash_reg + DEVICE_MAIN_AREA_SIZE) == 4096) &&
> - (ioread32(denali->flash_reg + DEVICE_SPARE_AREA_SIZE) == 64))
> - iowrite32(216, denali->flash_reg + DEVICE_SPARE_AREA_SIZE);
> -}
> -
> -static void get_hynix_nand_para(struct denali_nand_info *denali, u8
> device_id)
> -{
> - switch (device_id) {
> - case 0xD5: /* Hynix H27UAG8T2A, H27UBG8U5A or H27UCG8VFA */
> - case 0xD7: /* Hynix H27UDG8VEM, H27UCG8UDM or H27UCG8V5A */
> - iowrite32(128, denali->flash_reg + PAGES_PER_BLOCK);
> - iowrite32(4096, denali->flash_reg + DEVICE_MAIN_AREA_SIZE);
> - iowrite32(224, denali->flash_reg + DEVICE_SPARE_AREA_SIZE);
> - iowrite32(0, denali->flash_reg + DEVICE_WIDTH);
> - break;
> - default:
> - dev_warn(denali->dev,
> - "Unknown Hynix NAND (Device ID: 0x%x).\n"
> - "Will use default parameter values instead.\n",
> - device_id);
> - }
> -}
> -
> /*
> * determines how many NAND chips are connected to the controller. Note for
> * Intel CE4100 devices we don't support more than one device.
> @@ -468,10 +439,6 @@ static u16 denali_nand_timing_set(struct
> denali_nand_info *denali)
> return FAIL;
> } else if (maf_id == 0xEC) { /* Samsung NAND */
> get_samsung_nand_para(denali, device_id);
> - } else if (maf_id == 0x98) { /* Toshiba NAND */
> - get_toshiba_nand_para(denali);
> - } else if (maf_id == 0xAD) { /* Hynix NAND */
> - get_hynix_nand_para(denali, device_id);
> }
>
> dev_info(denali->dev,
> @@ -1661,6 +1628,12 @@ int denali_init(struct denali_nand_info *denali)
> chip->ecc.strength);
>
> iowrite32(chip->ecc.strength, denali->flash_reg + ECC_CORRECTION);
> + iowrite32(mtd->erasesize / mtd->writesize,
> + denali->flash_reg + PAGES_PER_BLOCK);
> + iowrite32(denali->nand.options & NAND_BUSWIDTH_16 ? 1 : 0,
> + denali->flash_reg + DEVICE_WIDTH);
> + iowrite32(mtd->writesize, denali->flash_reg + DEVICE_MAIN_AREA_SIZE);
> + iowrite32(mtd->oobsize, denali->flash_reg + DEVICE_SPARE_AREA_SIZE);
>
> mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
>
[PATCH] Scripts: kconfig: nconf: fix _GNU_SOURCE redefined warning
Fix below warning when make nconfig is run initially or after make clean. HOSTCC scripts/kconfig/nconf.o scripts/kconfig/nconf.c:8:0: warning: "_GNU_SOURCE" redefined #define _GNU_SOURCE ^ :0:0: note: this is the location of the previous definition Signed-off-by: Cheah Kok Cheong --- scripts/kconfig/nconf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c index d42d534..a9bc533 100644 --- a/scripts/kconfig/nconf.c +++ b/scripts/kconfig/nconf.c @@ -5,7 +5,9 @@ * Derived from menuconfig. * */ +#ifndef _GNU_SOURCE #define _GNU_SOURCE +#endif #include #include -- 2.7.4
Re: [PATCH 00/39] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb
On Sun, 27 Nov 2016 03:05:46 +0900
Masahiro Yamada wrote:
> As I said in the 1st round series, I am tackling on this driver
> to use it for my SoCs.
>
> The previous series was just cosmetic things, but this series
> includes *real* changes.
>
> After some more cleanups, I will start to add changes that
> are really necessary.
> One of the biggest problems I want to solve is a bunch of
> hard-coded parameters that prevent me from using this driver for
> my SoCs.
>
> I will introduce capability flags that are associated with DT
> compatible and make platform-dependent parameters overridable.
>
> I still have lots of reworks to get done (so probably 3rd round
> series will come), but I hope it is getting better and
> I am showing a big picture now.
>
I still need to carefully review some of those patches, but I must
admit I like some of the cleanups/rework you're doing here.
Thanks for all your work.
Boris
>
>
> Masahiro Yamada (39):
> mtd: nand: allow to set only one of ECC size and ECC strength from DT
> mtd: nand: denali: remove unused CONFIG option and macros
> mtd: nand: denali: remove redundant define of BANK(x)
> mtd: nand: denali: remove more unused struct members
> mtd: nand: denali: fix comment of denali_nand_info::flash_mem
> mtd: nand: denali: fix write_oob_data() function
> mtd: nand: denali: transfer OOB only when oob_required is set
> mtd: nand: denali: introduce capability flag
> mtd: nand: denali: fix erased page check code
> mtd: nand: denali: remove redundant if conditional of erased_check
> mtd: nand: denali: increment ecc_stats.failed by one per error
> mtd: nand: denali: return 0 for uncorrectable ECC error
> mtd: nand: denali: increment ecc_stats->corrected
> mtd: nand: denali: replace uint{8/16/32}_t with u{8/16/32}
> mtd: nand: denali: improve readability of handle_ecc()
> mtd: nand: denali: rename handle_ecc() to denali_sw_ecc_fixup()
> mtd: nand: denali: support HW_ECC_FIXUP capability
> mtd: nand: denali: move denali_read_page_raw() above
> denali_read_page()
> mtd: nand: denali: perform erased check against raw transferred page
> mtd: nand: denali_dt: enable HW_ECC_FIXUP capability for DT platform
> mtd: nand: denali: support 64bit capable DMA engine
> mtd: nand: denali_dt: remove dma-mask DT property
> mtd: nand: denali_dt: use pdev instead of ofdev for platform_device
> mtd: nand: denali: add NEW_N_BANKS_FORMAT capability
> mtd: nand: denali: use nand_chip to hold frequently accessed data
> mtd: nand: denali: call nand_set_flash_node() to set DT node
> mtd: nand: denali: do not set mtd->name
> mtd: nand: denali: move multi NAND fixup code to a helper function
> mtd: nand: denali: refactor multi NAND fixup code in more generic way
> mtd: nand: denali: set DEVICES_CONNECTED 1 if not set
> mtd: nand: denali: remove meaningless writes to read-only registers
> mtd: nand: denali: remove unnecessary writes to ECC_CORRECTION
> mtd: nand: denali: support 1024 byte ECC step size
> mtd: nand: denali: fix the condition for 15 bit ECC strength
> mtd: nand: denali: calculate ecc.strength and ecc.bytes generically
> mtd: nand: denali: allow to use SoC-specific ECC strength
> mtd: nand: denali: support "nand-ecc-strength" DT property
> mtd: nand: denali: remove Toshiba, Hynix specific fixup code
> mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
>
> .../devicetree/bindings/mtd/denali-nand.txt| 19 +-
> drivers/mtd/nand/Kconfig | 11 -
> drivers/mtd/nand/denali.c | 740
> -
> drivers/mtd/nand/denali.h | 84 +--
> drivers/mtd/nand/denali_dt.c | 95 ++-
> drivers/mtd/nand/denali_pci.c | 2 +
> drivers/mtd/nand/nand_base.c | 6 -
> 7 files changed, 515 insertions(+), 442 deletions(-)
>
[PATCH] md/raid5: limit request size according to implementation limits
Current implementation employ 16bit counter of active stripes in lower bits of bio->bi_phys_segments. If request is big enough to overflow this counter bio will be completed and freed too early. Fortunately this not happens in default configuration because several other limits prevent that: stripe_cache_size * nr_disks effectively limits count of active stripes. And small max_sectors_kb at lower disks prevent that during normal read/write operations. Overflow easily happens in discard if it's enabled by module parameter "devices_handle_discard_safely" and stripe_cache_size is set big enough. This patch limits requests size with 256Mb - 8Kb to prevent overflows. Signed-off-by: Konstantin Khlebnikov Cc: Shaohua Li Cc: Neil Brown Cc: sta...@vger.kernel.org --- drivers/md/raid5.c |9 + 1 file changed, 9 insertions(+) diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 92ac251e91e6..cce6057b9aca 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -6984,6 +6984,15 @@ static int raid5_run(struct mddev *mddev) stripe = (stripe | (stripe-1)) + 1; mddev->queue->limits.discard_alignment = stripe; mddev->queue->limits.discard_granularity = stripe; + + /* +* We use 16-bit counter of active stripes in bi_phys_segments +* (minus one for over-loaded initialization) +*/ + blk_queue_max_hw_sectors(mddev->queue, 0xfffe * STRIPE_SECTORS); + blk_queue_max_discard_sectors(mddev->queue, + 0xfffe * STRIPE_SECTORS); + /* * unaligned part of discard request will be ignored, so can't * guarantee discard_zeroes_data
Re: [PATCH 1/2] dt-bindings: usb: add DT binding for s3c2410 USB OHCI controller
On Fri, Nov 25, 2016 at 12:47:28PM -0200, Sergio Prado wrote:
> Adds the device tree bindings description for Samsung S3C2410 and
> compatible USB OHCI controller.
>
> Signed-off-by: Sergio Prado
> ---
> .../devicetree/bindings/usb/s3c2410-usb.txt| 22
> ++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/s3c2410-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
> b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
> new file mode 100644
> index ..e45b38ce2986
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
> @@ -0,0 +1,22 @@
> +Samsung S3C2410 and compatible SoC USB controller
> +
> +OHCI
> +
> +Required properties:
> + - compatible: should be "samsung,s3c2410-ohci" for USB host controller
> + - reg: address and lenght of the controller memory mapped region
s/lenght/length/
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
> + - interrupts: interrupt number for the USB OHCI controller
> + - clocks: Should reference the bus and host clocks
> + - clock-names: Should contain two strings
> + "usb-bus-host" for the USB bus clock
> + "usb-host" for the USB host clock
> +
> +Example:
> +
> +usb0: ohci@4900 {
> + compatible = "samsung,s3c2410-ohci";
> + reg = <0x4900 0x100>;
> + interrupts = <0 0 26 3>;
> + clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
> + clock-names = "usb-bus-host", "usb-host";
> +};
> --
> 1.9.1
>
Re: [PATCH 2/2] usb: ohci: s3c2410: allow probing from device tree
On Fri, Nov 25, 2016 at 12:47:29PM -0200, Sergio Prado wrote:
> Allows configuring Samsung's s3c2410 USB OHCI controller using a
> devicetree.
>
> Signed-off-by: Sergio Prado
> ---
> drivers/usb/host/ohci-s3c2410.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
> index 7a1919ca543a..d8e03a801f2e 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -457,6 +457,13 @@ static int ohci_hcd_s3c2410_drv_resume(struct device
> *dev)
> .resume = ohci_hcd_s3c2410_drv_resume,
> };
>
> +static const struct of_device_id ohci_hcd_s3c2410_dt_ids[] = {
> + { .compatible = "samsung,s3c2410-ohci" },
> + { /* sentinel */ }
> +};
> +
A nit, usually MODULE_DEVICE_TABLE comes right after the table, without
a blank line.
Beside that:
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
> +MODULE_DEVICE_TABLE(of, ohci_hcd_s3c2410_dt_ids);
> +
> static struct platform_driver ohci_hcd_s3c2410_driver = {
> .probe = ohci_hcd_s3c2410_drv_probe,
> .remove = ohci_hcd_s3c2410_drv_remove,
> @@ -464,6 +471,7 @@ static int ohci_hcd_s3c2410_drv_resume(struct device *dev)
> .driver = {
> .name = "s3c2410-ohci",
> .pm = &ohci_hcd_s3c2410_pm_ops,
> + .of_match_table = ohci_hcd_s3c2410_dt_ids,
> },
> };
>
> --
> 1.9.1
>
[PATCH v7 3/3] console: Add persistent scrollback buffers for all VGA consoles
Add a scrollback buffers for each VGA console. The benefit is that
the scrollback history is not flushed when switching between consoles
but is persistent.
The buffers are allocated on demand when a new console is opened.
This breaks tools like clear_console that rely on flushing the
scrollback history by switching back and forth between consoles
which is why this feature is disabled by default.
Use the escape sequence \e[3J instead for flushing the buffer.
Signed-off-by: Manuel Schölling
---
drivers/video/console/Kconfig | 25 +++-
drivers/video/console/vgacon.c | 142 ++---
2 files changed, 111 insertions(+), 56 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 38da6e2..c5742d2 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -43,9 +43,28 @@ config VGACON_SOFT_SCROLLBACK_SIZE
range 1 1024
default "64"
help
- Enter the amount of System RAM to allocate for the scrollback
-buffer. Each 64KB will give you approximately 16 80x25
-screenfuls of scrollback buffer
+ Enter the amount of System RAM to allocate for scrollback
+ buffers of VGA consoles. Each 64KB will give you approximately
+ 16 80x25 screenfuls of scrollback buffer.
+
+config VGACON_SOFT_SCROLLBACK_PERSISTENT
+ bool "Persistent Scrollback History for each console"
+ depends on VGACON_SOFT_SCROLLBACK
+ default n
+ help
+ Say Y here if the scrollback history should persist when switching
+ between consoles. Otherwise, the scrollback history will be flushed
+ each time the console is switched.
+
+ This feature might break your tool of choice to flush the scrollback
+ buffer, e.g. clear(1) will work fine but Debian's clear_console(1)
+ will be broken, which might cause security issues.
+ You can use the escape sequence \e[3J instead if this feature is
+ activated.
+
+ Note that a buffer of VGACON_SOFT_SCROLLBACK_SIZE is taken for each
+ created tty device.
+ So if you use a RAM-constrained system, say N here.
config MDA_CONSOLE
depends on !M68K && !PARISC && ISA
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 9a7c2bb..ca23d22 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -162,7 +162,7 @@ static inline void vga_set_mem_top(struct vc_data *c)
#ifdef CONFIG_VGACON_SOFT_SCROLLBACK
/* software scrollback */
-static struct vgacon_scrollback_info {
+struct vgacon_scrollback_info {
void *data;
int tail;
int size;
@@ -171,74 +171,110 @@ static struct vgacon_scrollback_info {
int cur;
int save;
int restore;
-} vgacon_scrollback;
+};
+
+static struct vgacon_scrollback_info *vgacon_scrollback_cur;
+#ifdef CONFIG_VGACON_SOFT_SCROLLBACK_PERSISTENT
+static struct vgacon_scrollback_info vgacon_scrollbacks[MAX_NR_CONSOLES];
+#else
+static struct vgacon_scrollback_info vgacon_scrollbacks[1];
+#endif
-static void vgacon_scrollback_reset(size_t reset_size)
+static void vgacon_scrollback_reset(int vc_num, size_t reset_size)
{
- if (vgacon_scrollback.data && reset_size > 0)
- memset(vgacon_scrollback.data, 0, reset_size);
+ struct vgacon_scrollback_info *scrollback = &vgacon_scrollbacks[vc_num];
+
+ if (scrollback->data && reset_size > 0)
+ memset(scrollback->data, 0, reset_size);
- vgacon_scrollback.cnt = 0;
- vgacon_scrollback.tail = 0;
- vgacon_scrollback.cur = 0;
+ scrollback->cnt = 0;
+ scrollback->tail = 0;
+ scrollback->cur = 0;
}
-static void vgacon_scrollback_init(int pitch)
+static void vgacon_scrollback_init(int vc_num)
{
- int rows = CONFIG_VGACON_SOFT_SCROLLBACK_SIZE * 1024/pitch;
-
- if (vgacon_scrollback.data) {
- vgacon_scrollback.cnt = 0;
- vgacon_scrollback.tail = 0;
- vgacon_scrollback.cur = 0;
- vgacon_scrollback.rows = rows - 1;
- vgacon_scrollback.size = rows * pitch;
+ int pitch = vga_video_num_columns * 2;
+ size_t size = CONFIG_VGACON_SOFT_SCROLLBACK_SIZE * 1024;
+ int rows = size / pitch;
+ void *data;
+
+ data = kmalloc_array(CONFIG_VGACON_SOFT_SCROLLBACK_SIZE, 1024,
+GFP_NOWAIT);
+
+ vgacon_scrollbacks[vc_num].data = data;
+ vgacon_scrollback_cur = &vgacon_scrollbacks[vc_num];
+
+ vgacon_scrollback_cur->rows = rows - 1;
+ vgacon_scrollback_cur->size = rows * pitch;
+
+ vgacon_scrollback_reset(vc_num, size);
+}
+
+static void vgacon_scrollback_switch(int vc_num)
+{
+#ifndef CONFIG_VGACON_SOFT_SCROLLBACK_PERSISTENT
+ vc_num = 0;
+#endif
+
+ if (!vgacon_scrollbacks[vc_num].data) {
+ vgacon_scrollback_init(vc_num);
+ } e
[PATCH v7 0/3] console: Add persistent scrollback buffers for all VGA consoles
Changes in v7: - Add new callback to consw struct for flushing video console driver's scrollback buffer. Fixes issues with escape sequence '\e[3J' reported by Adam Borowski (kilob...@angband.pl). - Fix style issues Changes in v6: - Change of check if feature is enabled in vgacon_scrollback_switch() Changes in v5: - Clearify documentation - Skip superfluous array initialization - Disable scrollback if buffer allocation fails - Refactor vgacon_switch_scrollback() - Rename vgacon_switch_scrollback() to vgacon_scrollback_switch() - Add check for fg_console in vgacon_scrollback_update Changes in v4.1: - Fix compiler error Changes in v4: - Rename from VGACON_SOFT_SCROLLBACK_FOR_EACH_CONSOLE to VGACON_SOFT_SCROLLBACK_PERSISTENT - Split into two patches - Rework documentation - Remove cosmetic changes in comments (postponed) Changes in v3: - Add config option for this feature - Fallback to old scrollback buffer if kcalloc() fails - Remove ioctl() call again and add documentation about existing escape sequence to flush the scrollback buffer Changes in v2: - Add ioctl() call to flush scrollback buffer - (Patch v2 was not labeled as such, sorry) Manuel Schölling (3): console: Move scrollback data into its own struct console: Add callback to flush scrollback buffer to consw struct console: Add persistent scrollback buffers for all VGA consoles drivers/tty/vt/vt.c| 9 +++ drivers/video/console/Kconfig | 25 ++- drivers/video/console/vgacon.c | 165 - include/linux/console.h| 4 + 4 files changed, 148 insertions(+), 55 deletions(-) -- 2.1.4
[PATCH v7 1/3] console: Move scrollback data into its own struct
This refactoring is in preparation for persistent scrollback
support for VGA console.
Signed-off-by: Manuel Schölling
---
drivers/video/console/vgacon.c | 91 ++
1 file changed, 47 insertions(+), 44 deletions(-)
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index c22a562..48b9764 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -162,31 +162,34 @@ static inline void vga_set_mem_top(struct vc_data *c)
#ifdef CONFIG_VGACON_SOFT_SCROLLBACK
/* software scrollback */
-static void *vgacon_scrollback;
-static int vgacon_scrollback_tail;
-static int vgacon_scrollback_size;
-static int vgacon_scrollback_rows;
-static int vgacon_scrollback_cnt;
-static int vgacon_scrollback_cur;
-static int vgacon_scrollback_save;
-static int vgacon_scrollback_restore;
+static struct vgacon_scrollback_info {
+ void *data;
+ int tail;
+ int size;
+ int rows;
+ int cnt;
+ int cur;
+ int save;
+ int restore;
+} vgacon_scrollback;
static void vgacon_scrollback_init(int pitch)
{
int rows = CONFIG_VGACON_SOFT_SCROLLBACK_SIZE * 1024/pitch;
- if (vgacon_scrollback) {
- vgacon_scrollback_cnt = 0;
- vgacon_scrollback_tail = 0;
- vgacon_scrollback_cur = 0;
- vgacon_scrollback_rows = rows - 1;
- vgacon_scrollback_size = rows * pitch;
+ if (vgacon_scrollback.data) {
+ vgacon_scrollback.cnt = 0;
+ vgacon_scrollback.tail = 0;
+ vgacon_scrollback.cur = 0;
+ vgacon_scrollback.rows = rows - 1;
+ vgacon_scrollback.size = rows * pitch;
}
}
static void vgacon_scrollback_startup(void)
{
- vgacon_scrollback = kcalloc(CONFIG_VGACON_SOFT_SCROLLBACK_SIZE, 1024,
GFP_NOWAIT);
+ vgacon_scrollback.data = kcalloc(CONFIG_VGACON_SOFT_SCROLLBACK_SIZE,
+ 1024, GFP_NOWAIT);
vgacon_scrollback_init(vga_video_num_columns * 2);
}
@@ -194,38 +197,38 @@ static void vgacon_scrollback_update(struct vc_data *c,
int t, int count)
{
void *p;
- if (!vgacon_scrollback_size || c->vc_num != fg_console)
+ if (!vgacon_scrollback.size || c->vc_num != fg_console)
return;
p = (void *) (c->vc_origin + t * c->vc_size_row);
while (count--) {
- scr_memcpyw(vgacon_scrollback + vgacon_scrollback_tail,
+ scr_memcpyw(vgacon_scrollback.data + vgacon_scrollback.tail,
p, c->vc_size_row);
- vgacon_scrollback_cnt++;
+ vgacon_scrollback.cnt++;
p += c->vc_size_row;
- vgacon_scrollback_tail += c->vc_size_row;
+ vgacon_scrollback.tail += c->vc_size_row;
- if (vgacon_scrollback_tail >= vgacon_scrollback_size)
- vgacon_scrollback_tail = 0;
+ if (vgacon_scrollback.tail >= vgacon_scrollback.size)
+ vgacon_scrollback.tail = 0;
- if (vgacon_scrollback_cnt > vgacon_scrollback_rows)
- vgacon_scrollback_cnt = vgacon_scrollback_rows;
+ if (vgacon_scrollback.cnt > vgacon_scrollback.rows)
+ vgacon_scrollback.cnt = vgacon_scrollback.rows;
- vgacon_scrollback_cur = vgacon_scrollback_cnt;
+ vgacon_scrollback.cur = vgacon_scrollback.cnt;
}
}
static void vgacon_restore_screen(struct vc_data *c)
{
- vgacon_scrollback_save = 0;
+ vgacon_scrollback.save = 0;
- if (!vga_is_gfx && !vgacon_scrollback_restore) {
+ if (!vga_is_gfx && !vgacon_scrollback.restore) {
scr_memcpyw((u16 *) c->vc_origin, (u16 *) c->vc_screenbuf,
c->vc_screenbuf_size > vga_vram_size ?
vga_vram_size : c->vc_screenbuf_size);
- vgacon_scrollback_restore = 1;
- vgacon_scrollback_cur = vgacon_scrollback_cnt;
+ vgacon_scrollback.restore = 1;
+ vgacon_scrollback.cur = vgacon_scrollback.cnt;
}
}
@@ -239,41 +242,41 @@ static void vgacon_scrolldelta(struct vc_data *c, int
lines)
return;
}
- if (!vgacon_scrollback)
+ if (!vgacon_scrollback.data)
return;
- if (!vgacon_scrollback_save) {
+ if (!vgacon_scrollback.save) {
vgacon_cursor(c, CM_ERASE);
vgacon_save_screen(c);
- vgacon_scrollback_save = 1;
+ vgacon_scrollback.save = 1;
}
- vgacon_scrollback_restore = 0;
- start = vgacon_scrollback_cur + lines;
+ vgacon_scrollback.restore = 0;
+ start = vgacon_scrollback.cur + lines;
end = start + abs(lines);
if (start < 0)
start = 0;
- if (start > vgacon_scrollback
[PATCH v7 2/3] console: Add callback to flush scrollback buffer to consw struct
This new callback is in preparation for persistent scrollback buffer
support for VGA consoles.
With a single scrollback buffer for all consoles, we could flush the
buffer just by invocating consw->con_switch(). But when each VGA console
has its own scrollback buffer, we need a new callback to tell the
video console driver which buffer to flush.
Signed-off-by: Manuel Schölling
---
drivers/tty/vt/vt.c| 9 +
drivers/video/console/vgacon.c | 24 +++-
include/linux/console.h| 4
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 4c10a9d..9d3ce50 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -625,6 +625,14 @@ static void save_screen(struct vc_data *vc)
vc->vc_sw->con_save_screen(vc);
}
+static void flush_scrollback(struct vc_data *vc)
+{
+ WARN_CONSOLE_UNLOCKED();
+
+ if (vc->vc_sw->con_flush_scrollback)
+ vc->vc_sw->con_flush_scrollback(vc);
+}
+
/*
* Redrawing of screen
*/
@@ -1171,6 +1179,7 @@ static void csi_J(struct vc_data *vc, int vpar)
case 3: /* erase scroll-back buffer (and whole display) */
scr_memsetw(vc->vc_screenbuf, vc->vc_video_erase_char,
vc->vc_screenbuf_size);
+ flush_scrollback(vc);
set_origin(vc);
if (con_is_visible(vc))
update_screen(vc);
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 48b9764..9a7c2bb 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -173,6 +173,16 @@ static struct vgacon_scrollback_info {
int restore;
} vgacon_scrollback;
+static void vgacon_scrollback_reset(size_t reset_size)
+{
+ if (vgacon_scrollback.data && reset_size > 0)
+ memset(vgacon_scrollback.data, 0, reset_size);
+
+ vgacon_scrollback.cnt = 0;
+ vgacon_scrollback.tail = 0;
+ vgacon_scrollback.cur = 0;
+}
+
static void vgacon_scrollback_init(int pitch)
{
int rows = CONFIG_VGACON_SOFT_SCROLLBACK_SIZE * 1024/pitch;
@@ -305,6 +315,14 @@ static void vgacon_scrolldelta(struct vc_data *c, int
lines)
} else
vgacon_cursor(c, CM_MOVE);
}
+
+static void vgacon_flush_scrollback(struct vc_data *c)
+{
+ size_t size = CONFIG_VGACON_SOFT_SCROLLBACK_SIZE * 1024;
+
+ if (c->vc_num == fg_console)
+ vgacon_scrollback_reset(size);
+}
#else
#define vgacon_scrollback_startup(...) do { } while (0)
#define vgacon_scrollback_init(...)do { } while (0)
@@ -322,6 +340,10 @@ static void vgacon_scrolldelta(struct vc_data *c, int
lines)
vga_vram_size);
vga_set_mem_top(c);
}
+
+static void vgacon_flush_scrollback(struct vc_data *c)
+{
+}
#endif /* CONFIG_VGACON_SOFT_SCROLLBACK */
static const char *vgacon_startup(void)
@@ -1329,7 +1351,6 @@ static bool vgacon_scroll(struct vc_data *c, unsigned int
t, unsigned int b,
return true;
}
-
/*
* The console `switch' structure for the VGA based console
*/
@@ -1362,6 +1383,7 @@ const struct consw vga_con = {
.con_save_screen = vgacon_save_screen,
.con_build_attr = vgacon_build_attr,
.con_invert_region = vgacon_invert_region,
+ .con_flush_scrollback = vgacon_flush_scrollback,
};
EXPORT_SYMBOL(vga_con);
diff --git a/include/linux/console.h b/include/linux/console.h
index 9c26c66..5949d18 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -73,6 +73,10 @@ struct consw {
u16*(*con_screen_pos)(struct vc_data *, int);
unsigned long (*con_getxy)(struct vc_data *, unsigned long, int *, int
*);
/*
+* Flush the video console driver's scrollback buffer
+*/
+ void(*con_flush_scrollback)(struct vc_data *);
+ /*
* Prepare the console for the debugger. This includes, but is not
* limited to, unblanking the console, loading an appropriate
* palette, and allowing debugger generated output.
--
2.1.4
[PATCH] wireless: ath: ath9k: constify ath_bus_ops structure
Declare the structure ath_bus_ops as const as it is only passed as an
argument to the function ath9k_init_device. This argument is of type
const struct ath_bus_ops *, so ath_bus_ops structures with this property
can be declared as const.
Done using Coccinelle:
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct ath_bus_ops i@p = {...};
@ok1@
identifier r1.i;
position p;
expression e1,e2;
@@
ath9k_init_device(e1,e2,&i@p)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct ath_bus_ops i={...};
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct ath_bus_ops i;
File size before:
textdata bss dec hex filename
1295 232 01527 5f7 ath/ath9k/ahb.o
File size after:
textdata bss dec hex filename
1359 176 01535 5ff ath/ath9k/ahb.o
Signed-off-by: Bhumika Goyal
---
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ahb.c
b/drivers/net/wireless/ath/ath9k/ahb.c
index bea6186..2bd982c 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -62,7 +62,7 @@ static bool ath_ahb_eeprom_read(struct ath_common *common,
u32 off, u16 *data)
return false;
}
-static struct ath_bus_ops ath_ahb_bus_ops = {
+static const struct ath_bus_ops ath_ahb_bus_ops = {
.ath_bus_type = ATH_AHB,
.read_cachesize = ath_ahb_read_cachesize,
.eeprom_read = ath_ahb_eeprom_read,
--
1.9.1
[PATCH] fs: xfs: libxfs: constify xfs_nameops structures
Declare the structure xfs_nameops as const as it is only stored in the
m_dirnameops field of a xfs_mount structure. This field is of type
const struct xfs_nameops *, so xfs_nameops structures having this
property can be declared as const.
Done using Coccinelle:
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct xfs_nameops i@p = {...};
@ok1@
identifier r1.i;
position p;
struct xfs_mount mp;
@@
mp.m_dirnameops=&i@p
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct xfs_nameops i={...};
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct xfs_nameops i;
File size before:
textdata bss dec hex filename
5302 85 05387150b fs/xfs/libxfs/xfs_dir2.o
File size after:
textdata bss dec hex filename
5318 69 05387150b fs/xfs/libxfs/xfs_dir2.o
Signed-off-by: Bhumika Goyal
---
fs/xfs/libxfs/xfs_dir2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/libxfs/xfs_dir2.c b/fs/xfs/libxfs/xfs_dir2.c
index 20a96dd..c58d72c 100644
--- a/fs/xfs/libxfs/xfs_dir2.c
+++ b/fs/xfs/libxfs/xfs_dir2.c
@@ -93,7 +93,7 @@
return result;
}
-static struct xfs_nameops xfs_ascii_ci_nameops = {
+static const struct xfs_nameops xfs_ascii_ci_nameops = {
.hashname = xfs_ascii_ci_hashname,
.compname = xfs_ascii_ci_compname,
};
--
1.9.1
Re: [PATCH 00/29] UBIFS File Encryption v1
On Fri, Nov 25, 2016 at 09:18:12AM +0100, Richard Weinberger wrote: > > Do you want us to address Eric's review comments on top of the fscrypt > branch or shall we rebase? > I'd suggest the former. Yes, let's address them on top of the existing fscrypt branch. I don't consider any of his comments super-serious --- they were mostly documentation or comments level changes unless I missed something. - Ted
Re: [PATCH v3 net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
Hello Lino,
just some things barely worth mentioning:
On 11/26/2016 01:20 PM, Lino Sanfilippo wrote:
> Add driver for Alacritech gigabit ethernet cards with SLIC (session-layer
> interface control) technology. The driver provides basic support without
> SLIC for the following devices:
>
> - Mojave cards (single port PCI Gigabit) both copper and fiber
> - Oasis cards (single and dual port PCI-x Gigabit) copper and fiber
> - Kalahari cards (dual and quad port PCI-e Gigabit) copper and fiber
>
> Signed-off-by: Lino Sanfilippo
> ---
> drivers/net/ethernet/Kconfig |1 +
> drivers/net/ethernet/Makefile |1 +
> drivers/net/ethernet/alacritech/Kconfig | 28 +
> drivers/net/ethernet/alacritech/Makefile |4 +
> drivers/net/ethernet/alacritech/slic.h| 576 +
> drivers/net/ethernet/alacritech/slicoss.c | 1867
> +
> 6 files changed, 2477 insertions(+)
> create mode 100644 drivers/net/ethernet/alacritech/Kconfig
> create mode 100644 drivers/net/ethernet/alacritech/Makefile
> create mode 100644 drivers/net/ethernet/alacritech/slic.h
> create mode 100644 drivers/net/ethernet/alacritech/slicoss.c
>
[...]
> diff --git a/drivers/net/ethernet/alacritech/slic.h
> b/drivers/net/ethernet/alacritech/slic.h
> new file mode 100644
> index 000..c62d46b
> --- /dev/null
> +++ b/drivers/net/ethernet/alacritech/slic.h
> @@ -0,0 +1,576 @@
> +
> +#ifndef _SLIC_H
> +#define _SLIC_H
I found a bunch of unused #defines in slic.h. I cannot judge if they are
worth keeping:
SLIC_VRHSTATB_LONGE
SLIC_VRHSTATB_PREA
SLIC_ISR_IO
SLIC_ISR_PING_MASK
SLIC_GIG_SPEED_MASK
SLIC_GMCR_RESET
SLIC_XCR_RESET
SLIC_XCR_XMTEN
SLIC_XCR_PAUSEEN
SLIC_XCR_LOADRNG
SLIC_REG_DBAR
SLIC_REG_PING
SLIC_REG_DUMP_CMD
SLIC_REG_DUMP_DATA
SLIC_REG_WRHOSTID
SLIC_REG_LOW_POWER
SLIC_REG_RESET_IFACE
SLIC_REG_ADDR_UPPER
SLIC_REG_HBAR64
SLIC_REG_DBAR64
SLIC_REG_CBAR64
SLIC_REG_RBAR64
SLIC_REG_WRVLANID
SLIC_REG_READ_XF_INFO
SLIC_REG_WRITE_XF_INFO
SLIC_REG_TICKS_PER_SEC
These device IDs are not used, either, but maybe it's good to keep them
for documentation purposes:
PCI_SUBDEVICE_ID_ALACRITECH_1000X1_2
PCI_SUBDEVICE_ID_ALACRITECH_SES1001T
PCI_SUBDEVICE_ID_ALACRITECH_SEN2002XT
PCI_SUBDEVICE_ID_ALACRITECH_SEN2001XT
PCI_SUBDEVICE_ID_ALACRITECH_SEN2104ET
PCI_SUBDEVICE_ID_ALACRITECH_SEN2102ET
[...]
> +
> +/* SLIC EEPROM structure for Oasis */
> +struct slic_mojave_eeprom {
Comment: "for Mojave".
[...]
> +struct slic_device {
> + struct pci_dev *pdev;
> + struct net_device *netdev;
> + void __iomem *regs;
> + /* upper address setting lock */
> + spinlock_t upper_lock;
> + struct slic_shmem shmem;
> + struct napi_struct napi;
> + struct slic_rx_queue rxq;
> + struct slic_tx_queue txq;
> + struct slic_stat_queue stq;
> + struct slic_stats stats;
> + struct slic_upr_list upr_list;
> + /* link configuration lock */
> + spinlock_t link_lock;
> + bool promisc;
> + bool autoneg;
> + int speed;
> + int duplex;
Maybe make speed and duplex unsigned? They are assigned and compared
against unsigned values in slicoss.c, so this would get rid of some
(benign, because of the range of the values) -Wsign-compare warnings in
slic_configure_link_locked. However, in a comparison there SPEED_UNKNOWN
would need to be casted to unsigned to prevent another one popping up.
[...]
> +#endif /* _SLIC_H */
> diff --git a/drivers/net/ethernet/alacritech/slicoss.c
> b/drivers/net/ethernet/alacritech/slicoss.c
> new file mode 100644
> index 000..8cd862a
> --- /dev/null
> +++ b/drivers/net/ethernet/alacritech/slicoss.c
> @@ -0,0 +1,1867 @@
[...]
> +
> +static const struct pci_device_id slic_id_tbl[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_ALACRITECH,
> + PCI_DEVICE_ID_ALACRITECH_MOAVE) },
I missed this in slic.h, but is this a typo and "MOAVE" should be
"MOJAVE"? There are a couple similar #defines in slic.h.
[...]
> +static void slic_refill_rx_queue(struct slic_device *sdev, gfp_t gfp)
> +{
> + const unsigned int ALIGN_MASK = SLIC_RX_BUFF_ALIGN - 1;
> + unsigned int maplen = SLIC_RX_BUFF_SIZE;
> + struct slic_rx_queue *rxq = &sdev->rxq;
> + struct net_device *dev = sdev->netdev;
> + struct slic_rx_buffer *buff;
> + struct slic_rx_desc *desc;
> + unsigned int misalign;
> + unsigned int offset;
> + struct sk_buff *skb;
> + dma_addr_t paddr;
> +
> + while (slic_get_free_rx_descs(rxq) > SLIC_MAX_REQ_RX_DESCS) {
> + skb = alloc_skb(maplen + ALIGN_MASK, gfp);
> + if (!skb)
> + break;
> +
> + paddr = dma_map_single(&sdev->pdev->dev, skb->data, maplen,
> +
Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup
On Sun, 27 Nov 2016, "S. Fricke" wrote: > Hi Peter, > >> On Fri, Nov 25, 2016 at 03:59:45PM +0100, Silvio Fricke wrote: >> > ... and move to core-api folder. >> > >> > Signed-off-by: Silvio Fricke >> > --- >> > Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | >> > 777 >> > +--- >> > Documentation/core-api/index.rst | >> > 1 +- >> > Documentation/process/volatile-considered-harmful.rst | >> > 3 +- >> > 3 files changed, 404 insertions(+), 377 deletions(-) >> >> Not a fan of this. The atomic_ops.txt file needs a lot of love, and I >> wouldn't want to edit a .rst file. > > What is the problem with this rst-file? atomic_ops.rst are not so > different to the txt variant. There is nothing particularly wrong with the patch. Perhaps you could leave the tabs in place instead of indenting with spaces in the code blocks. It would result in a smaller diff. But other than that, it's fine. I'm sure Peter is capable of editing a file with a .rst extension, and we can clean up any hickups afterwards if getting the formatting right is insurmountable. > I will drop this patch. Please don't. Please let Jon be the judge of that. Thanks, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
To more consistently reference nodes by label, add labels for sata,
usb2, sdhci and usb3 nodes.
Convert all other 38x boards for consistency. Add labels for nfc and rtc.
Signed-off-by: Andreas Färber
---
arch/arm/boot/dts/armada-385-db-ap.dts | 334 +++--
arch/arm/boot/dts/armada-385-linksys-caiman.dts| 98 ++--
arch/arm/boot/dts/armada-385-linksys-cobra.dts | 98 ++--
arch/arm/boot/dts/armada-385-linksys.dtsi | 294 ++-
arch/arm/boot/dts/armada-385-turris-omnia.dts | 97 ++--
arch/arm/boot/dts/armada-385.dtsi | 20 +-
arch/arm/boot/dts/armada-388-clearfog.dts | 550 ++---
arch/arm/boot/dts/armada-388-db.dts| 236 -
arch/arm/boot/dts/armada-388-gp.dts| 403 ---
arch/arm/boot/dts/armada-388-rd.dts| 115 +++--
arch/arm/boot/dts/armada-388.dtsi | 19 +-
.../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 111 ++---
arch/arm/boot/dts/armada-38x.dtsi | 16 +-
13 files changed, 1170 insertions(+), 1221 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts
b/arch/arm/boot/dts/armada-385-db-ap.dts
index db5b9f6..9b67716 100644
--- a/arch/arm/boot/dts/armada-385-db-ap.dts
+++ b/arch/arm/boot/dts/armada-385-db-ap.dts
@@ -63,174 +63,6 @@
MBUS_ID(0x09, 0x19) 0 0xf110 0x1
MBUS_ID(0x09, 0x15) 0 0xf111 0x1
MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
-
- internal-regs {
- i2c0: i2c@11000 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
- status = "okay";
-
- /*
-* This bus is wired to two EEPROM
-* sockets, one of which holding the
-* board ID used by the bootloader.
-* Erasing this EEPROM's content will
-* brick the board.
-* Use this bus with caution.
-*/
- };
-
- mdio@72004 {
- pinctrl-names = "default";
- pinctrl-0 = <&mdio_pins>;
-
- phy0: ethernet-phy@1 {
- reg = <1>;
- };
-
- phy1: ethernet-phy@4 {
- reg = <4>;
- };
-
- phy2: ethernet-phy@6 {
- reg = <6>;
- };
- };
-
- /* UART0 is exposed through the JP8 connector */
- uart0: serial@12000 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
- status = "okay";
- };
-
- /*
-* UART1 is exposed through a FTDI chip
-* wired to the mini-USB connector
-*/
- uart1: serial@12100 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins>;
- status = "okay";
- };
-
- pinctrl@18000 {
- xhci0_vbus_pins: xhci0-vbus-pins {
- marvell,pins = "mpp44";
- marvell,function = "gpio";
- };
- };
-
- /* CON3 */
- ethernet@3 {
- status = "okay";
- phy = <&phy2>;
- phy-mode = "sgmii";
- buffer-manager = <&bm>;
- bm,pool-long = <1>;
- bm,pool-short = <3>;
- };
-
- /* CON2 */
- ethernet@34000 {
- status = "okay";
- phy = <&phy1>;
- phy-mode = "sgmii";
- buffer-manager = <&bm>;
- bm,pool-long = <2>;
- bm,pool-short = <3>;
- };
-
- usb@58000 {
- status = "okay";
- };
-
- /* CON4 */
- ethernet@7 {
- p
Re: [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
Am 27.11.2016 um 19:51 schrieb Andreas Färber:
> To more consistently reference nodes by label, add labels for sata,
> usb2, sdhci and usb3 nodes.
s/usb2/usb/ to be fully correct.
>
> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
>
> Signed-off-by: Andreas Färber
> ---
> arch/arm/boot/dts/armada-385-db-ap.dts | 334 +++--
> arch/arm/boot/dts/armada-385-linksys-caiman.dts| 98 ++--
> arch/arm/boot/dts/armada-385-linksys-cobra.dts | 98 ++--
> arch/arm/boot/dts/armada-385-linksys.dtsi | 294 ++-
> arch/arm/boot/dts/armada-385-turris-omnia.dts | 97 ++--
> arch/arm/boot/dts/armada-385.dtsi | 20 +-
> arch/arm/boot/dts/armada-388-clearfog.dts | 550
> ++---
> arch/arm/boot/dts/armada-388-db.dts| 236 -
> arch/arm/boot/dts/armada-388-gp.dts| 403 ---
> arch/arm/boot/dts/armada-388-rd.dts| 115 +++--
> arch/arm/boot/dts/armada-388.dtsi | 19 +-
> .../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 111 ++---
> arch/arm/boot/dts/armada-38x.dtsi | 16 +-
> 13 files changed, 1170 insertions(+), 1221 deletions(-)
[...]
> diff --git a/arch/arm/boot/dts/armada-388.dtsi
> b/arch/arm/boot/dts/armada-388.dtsi
> index 564fa59..1a7fc5d 100644
> --- a/arch/arm/boot/dts/armada-388.dtsi
> +++ b/arch/arm/boot/dts/armada-388.dtsi
> @@ -50,21 +50,8 @@
> model = "Marvell Armada 388 family SoC";
> compatible = "marvell,armada388", "marvell,armada385",
> "marvell,armada380";
> +};
>
> - soc {
> - internal-regs {
> - pinctrl@18000 {
> - compatible = "marvell,mv88f6828-pinctrl";
> - };
> -
> - sata@e {
> - compatible = "marvell,armada-380-ahci";
> - reg = <0xe 0x2000>;
> - interrupts = ;
> - clocks = <&gateclk 30>;
> - status = "disabled";
> - };
Note that this sata node is redundant with armada-38x.dtsi by my
reading, therefore dropped.
> -
> - };
> - };
> +&pinctrl {
> + compatible = "marvell,mv88f6828-pinctrl";
> };
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Re: Question: goal of twice disabling of preemption in exception handlers
On Sun, Nov 20, 2016 at 9:52 AM, Alexnader Kuleshov wrote: > Hello everyone, > > Exception handlers which may run on IST stack disable and enable preemption > twice. For example do_int3() [1]. This one calls ist_enter() which > disables preemption with preempt_disable() every time without any conditions. > And later do_int3() calls preempt_disable() again [2] before do_trap(). > > Of course we decrement preemption counter in the end of such exception > handlers twice too. But what's actual purpose of doing this two times? > > [1] > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/x86/kernel/traps.c?id=refs/tags/next-20161117#n530 > [2] > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/x86/kernel/traps.c?id=refs/tags/next-20161117#n566 > > Thank you. You could submit a patch to get rid of the extra one if you like.
[PATCH] ARM: dts: mvebu: Fix armada-385-turris-omnia stdout-path
Specify the baudrate.
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-König
Signed-off-by: Andreas Färber
---
arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts
b/arch/arm/boot/dts/armada-385-turris-omnia.dts
index f53cb8b73610..2eff012287d4 100644
--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -52,7 +52,7 @@
compatible = "cznic,turris-omnia", "marvell,armada385",
"marvell,armada380";
chosen {
- stdout-path = &uart0;
+ stdout-path = "serial0:115200n8";
};
memory {
--
2.6.6
Re: Question: goal of twice disabling of preemption in exception handlers
On 11-27-16, Andy Lutomirski wrote: > On Sun, Nov 20, 2016 at 9:52 AM, Alexnader Kuleshov > wrote: > > Hello everyone, > > > > Exception handlers which may run on IST stack disable and enable preemption > > twice. For example do_int3() [1]. This one calls ist_enter() which > > disables preemption with preempt_disable() every time without any > > conditions. > > And later do_int3() calls preempt_disable() again [2] before do_trap(). > > > > Of course we decrement preemption counter in the end of such exception > > handlers twice too. But what's actual purpose of doing this two times? > > > > [1] > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/x86/kernel/traps.c?id=refs/tags/next-20161117#n530 > > [2] > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/x86/kernel/traps.c?id=refs/tags/next-20161117#n566 > > > > Thank you. > > You could submit a patch to get rid of the extra one if you like. Thanks for reply. Will send a patch.
[PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline
Found while reviewing Marvell dsa bindings usage.
Fixes: f283745b3caf ("arm: vf610: zii devel b: Add support for switch
interrupts")
Cc: Andrew Lunn
Cc: David S. Miller
Signed-off-by: Andreas Färber
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 7ea617e47fe4..958b4c42d320 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -153,7 +153,8 @@
switch0phy1: switch1phy0@1 {
reg = <1>;
interrupt-parent = <&switch0>;
- interrupts = <1
IRQ_TYPE_LEVEL_HIGH>; };
+ interrupts = <1
IRQ_TYPE_LEVEL_HIGH>;
+ };
switch0phy2: switch1phy0@2 {
reg = <2>;
interrupt-parent = <&switch0>;
--
2.6.6
[PATCH v3 1/2] of: Fix issue where code would fall through to error case.
No longer fall through into the error case that prints out
an error if no error (err = 0) occurred.
Rework error handling to print error where it occured instead
of having a global catch-all at the end of the function.
Fixes d9181b20a83(of: Add back an error message, restructured)
Signed-off-by: Moritz Fischer
Reviewed-by: Frank Rowand
---
Hi Rob, Frank
this has already Frank's Reviewed-by: tag on it, but since I changed around the
earlier part (before tree_node gets assigned) Frank might wanna take another
look
at this.
Changes from v2:
* Change error printouts to print error where it's produced
* Before tree_symbols gets assigned a non-NULL value, directly return error
instead of goto out, since of_put_node will be a no-op for !tree_symbols
Changes from v1:
* Implemented Frank's suggestion
Cheers,
Moritz
---
drivers/of/resolver.c | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 783bd09..5f51a4a 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -296,14 +296,12 @@ int of_resolve_phandles(struct device_node *overlay)
tree_symbols = NULL;
if (!overlay) {
- pr_err("null overlay\n");
- err = -EINVAL;
- goto err_out;
+ pr_err("overlay phandle fixup failed: null overlay\n");
+ return -EINVAL;
}
if (!of_node_check_flag(overlay, OF_DETACHED)) {
- pr_err("overlay not detached\n");
- err = -EINVAL;
- goto err_out;
+ pr_err("overlay phandle fixup failed: overlay not detached\n");
+ return -EINVAL;
}
phandle_delta = live_tree_max_phandle() + 1;
@@ -314,8 +312,10 @@ int of_resolve_phandles(struct device_node *overlay)
break;
err = adjust_local_phandle_references(local_fixups, overlay,
phandle_delta);
- if (err)
- goto err_out;
+ if (err) {
+ pr_err("overlay phandle fixup failed: %d\n", err);
+ return err;
+ }
overlay_fixups = NULL;
@@ -324,16 +324,13 @@ int of_resolve_phandles(struct device_node *overlay)
overlay_fixups = child;
}
- if (!overlay_fixups) {
- err = 0;
- goto out;
- }
+ if (!overlay_fixups)
+ return 0;
tree_symbols = of_find_node_by_path("/__symbols__");
if (!tree_symbols) {
- pr_err("no symbols in root of device tree.\n");
- err = -EINVAL;
- goto err_out;
+ pr_err("overlay phandle fixup failed: no symbols in root\n");
+ return -EINVAL;
}
for_each_property_of_node(overlay_fixups, prop) {
@@ -344,13 +341,16 @@ int of_resolve_phandles(struct device_node *overlay)
err = of_property_read_string(tree_symbols,
prop->name, &refpath);
- if (err)
- goto err_out;
+ if (err) {
+ pr_err("overlay phandle fixup failed: %d\n", err);
+ goto out;
+ }
refnode = of_find_node_by_path(refpath);
if (!refnode) {
err = -ENOENT;
- goto err_out;
+ pr_err("overlay phandle fixup failed: !refnode\n");
+ goto out;
}
phandle = refnode->phandle;
@@ -361,8 +361,6 @@ int of_resolve_phandles(struct device_node *overlay)
break;
}
-err_out:
- pr_err("overlay phandle fixup failed: %d\n", err);
out:
of_node_put(tree_symbols);
--
2.7.4
[PATCH v3 2/2] of: resolver: Fix checkpatch warnings
Fix two line over 80 character warnings that checkpatch spit out:
Before:
total: 0 errors, 2 warnings, 374 lines checked
drivers/of/resolver.c has style problems, please review.
After:
total: 0 errors, 0 warnings, 376 lines checked
Signed-off-by: Moritz Fischer
---
Hi,
this one just silences two checkpatch warnings that I ran
into when running checkpatch against my patches.
There's a bunch of 'CHECK' level things in this file that
I could address in a follow up patch if desired.
Cheers,
Moritz
---
drivers/of/resolver.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 5f51a4a..71f98dc 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -311,7 +311,8 @@ int of_resolve_phandles(struct device_node *overlay)
if (!of_node_cmp(local_fixups->name, "__local_fixups__"))
break;
- err = adjust_local_phandle_references(local_fixups, overlay,
phandle_delta);
+ err = adjust_local_phandle_references(local_fixups, overlay,
+ phandle_delta);
if (err) {
pr_err("overlay phandle fixup failed: %d\n", err);
return err;
@@ -356,7 +357,8 @@ int of_resolve_phandles(struct device_node *overlay)
phandle = refnode->phandle;
of_node_put(refnode);
- err = update_usages_of_a_phandle_reference(overlay, prop,
phandle);
+ err = update_usages_of_a_phandle_reference(overlay, prop,
+ phandle);
if (err)
break;
}
--
2.7.4
Re: [PATCH v2] ipv6:ipv6_pinfo dereferenced after NULL check
From: Manjeet Pawar Date: Thu, 24 Nov 2016 16:11:57 +0530 > From: Rohit Thapliyal > > np checked for NULL and then dereferenced. It should be modified > for NULL case. > > Signed-off-by: Rohit Thapliyal > Signed-off-by: Manjeet Pawar > Signed-off-by: Hannes Frederic Sowa > Reviewed-by: Akhilesh Kumar I do not think inet6_sk(sk) can ever be NULL in this function. All callers fall into two categories: 1) Calls where arguments already dereference np in some way to pass arguments to ip6_xmit(): net/dccp/ipv6.c:err = ip6_xmit(sk, skb, &fl6, opt, np->tclass); net/ipv6/inet6_connection_sock.c: res = ip6_xmit(sk, skb, &fl6, rcu_dereference(np->opt), net/ipv6/tcp_ipv6.c:err = ip6_xmit(sk, skb, fl6, opt, np->tclass); net/sctp/ipv6.c:res = ip6_xmit(sk, skb, fl6, rcu_dereference(np->opt), np->tclass); 2) Calls where the socket is a "control" socket which is initialized at procotol registration time and therefore definitely has a proper inet6_sk() pointer set up. net/dccp/ipv6.c:ip6_xmit(ctl_sk, skb, &fl6, NULL, 0); net/ipv6/tcp_ipv6.c:ip6_xmit(ctl_sk, buff, &fl6, NULL, tclass); Therefore, I think we should simply remove the NULL test entirely.
Re: [PATCH] platform/chrome : Add myself as Maintainer
On Wed, Nov 16, 2016 at 10:19 AM, Benson Leung wrote: > I'll be taking over maintainership of platform/chrome from Olof, > so let's add me to the list of maintainers. > > Signed-off-by: Benson Leung Acked-by: Olof Johansson I talked to Darren at Plumbers about drivers/platform/chrome, and whether he was open to merge that contents through his drivers/platform tree, and he was open to that. Darren, meet Benson -- Benson will be picking up maintainership of the chrome platform code since I no longer have good access to hardware to test new changes. We didn't talk about the method of merging, if you prefer to get patches sent directly to you or if you're OK with merging a git branch from Benson. The latter might be easier for Benson, the former might be easier for you. In the past, the amount of code coming in through the platform/chrome tree has been relatively small, it's mostly been a matter of acking drivers going in through MFD or other trees. The main reason to split them out to a separate platform directory has been because it cuts across architectures and none of the previous ones were a good fit (i.e. drivers/platform/x86 was too narrow). I expect that to stay true as long as there are ARM Chromebooks, which is hopefully forever. :) -Olof
[PATCH] mv88e6xxx: Fix mv88e6xxx_g1_irq_free() interrupt count
mv88e6xxx_g1_irq_setup() sets up chip->g1_irq.nirqs interrupt mappings,
so free the same amount. This will be 8 or 9 in practice, less than 16.
Fixes: dc30c35be720 ("net: dsa: mv88e6xxx: Implement interrupt support.")
Cc: Andrew Lunn
Signed-off-by: Andreas Färber
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 98302358ceb9..95b9efb33ec7 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -421,7 +421,7 @@ static void mv88e6xxx_g1_irq_free(struct mv88e6xxx_chip
*chip)
free_irq(chip->irq, chip);
- for (irq = 0; irq < 16; irq++) {
+ for (irq = 0; irq < chip->g1_irq.nirqs; irq++) {
virq = irq_find_mapping(chip->g1_irq.domain, irq);
irq_dispose_mapping(virq);
}
--
2.6.6
Re: [PATCH] netdevice: fix sparse warning for HARD_TX_LOCK
From: "Michael S. Tsirkin" Date: Thu, 24 Nov 2016 07:04:08 +0200 > sparse warns about context imbalance in any code > that uses HARD_TX_LOCK/UNLOCK - this is because it's > unable to determine that flags don't change so > lock and unlock are paired. > > Seems easy enough to fix by adding __acquire/__release > calls. > > With this patch af_packet.c is now sparse-clean, > > Signed-off-by: Michael S. Tsirkin Applied to net-next, thanks.
[PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
This model is found on the Turris Omnia.
Signed-off-by: Andreas Färber
---
drivers/net/dsa/mv88e6xxx/chip.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 77f13ada2612..95b9efb33ec7 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4280,6 +4280,10 @@ static const struct of_device_id mv88e6xxx_of_match[] = {
.data = &mv88e6xxx_table[MV88E6085],
},
{
+ .compatible = "marvell,mv88e6176",
+ .data = &mv88e6xxx_table[MV88E6176],
+ },
+ {
.compatible = "marvell,mv88e6190",
.data = &mv88e6xxx_table[MV88E6190],
},
--
2.6.6
[PATCH 1/2] Documentation: net: dsa: marvell: Add 88E6176
Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/net/dsa/marvell.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt index b3dd6b40e0de..000bc3b16edd 100644 --- a/Documentation/devicetree/bindings/net/dsa/marvell.txt +++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt @@ -15,6 +15,7 @@ Additional required and optional properties can be found in dsa.txt. Required properties: - compatible : Should be one of "marvell,mv88e6085" or +"marvell,mv88e6176" or "marvell,mv88e6190" - reg : Address on the MII bus for the switch. -- 2.6.6
[PATCH] MAINTAINERS: Add device tree bindings to mv88e6xx section
Also include the netdev list for convenience, as done elsewhere. Cc: Andrew Lunn Cc: Vivien Didelot Signed-off-by: Andreas Färber --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index f73e19277a70..46ccf6eadcc9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7670,6 +7670,7 @@ M:Andrew Lunn M: Vivien Didelot S: Maintained F: drivers/net/dsa/mv88e6xxx/ +F: Documentation/devicetree/bindings/net/dsa/marvell.txt MARVELL ARMADA DRM SUPPORT M: Russell King -- 2.6.6
[PATCH v2] MAINTAINERS: Add device tree bindings to mv88e6xx section
Also include the netdev list for convenience, as done elsewhere. Cc: Andrew Lunn Cc: Vivien Didelot Signed-off-by: Andreas Färber --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f73e19277a70..677d73cfedc7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7668,8 +7668,10 @@ S: Maintained MARVELL 88E6XXX ETHERNET SWITCH FABRIC DRIVER M: Andrew Lunn M: Vivien Didelot +L: net...@vger.kernel.org S: Maintained F: drivers/net/dsa/mv88e6xxx/ +F: Documentation/devicetree/bindings/net/dsa/marvell.txt MARVELL ARMADA DRM SUPPORT M: Russell King -- 2.6.6
Re: [PATCH] ARM: dts: mvebu: Fix armada-385-turris-omnia stdout-path
On Sun, Nov 27, 2016 at 08:37:24PM +0100, Andreas Färber wrote:
> Specify the baudrate.
Hi Andreas
Please put each patch/patchset in a new thread.
> Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
> Cc: Uwe Kleine-König
> Signed-off-by: Andreas Färber
Reviewed-by: Andrew Lunn
Andrew
Re: RFC: documentation of the autogroup feature
Hi Mike, On 11/23/2016 04:33 PM, Mike Galbraith wrote: > On Wed, 2016-11-23 at 14:54 +0100, Michael Kerrisk (man-pages) wrote: >> Hi Mike, [...] >> Actually, can you define for me what the root task group is, and >> why it exists? That may be worth some words in this man page. > > I don't think we need group scheduling details, there's plenty of > documentation elsewhere for those who want theory. Autogroup is for > those who don't want to have to care (which is also why it should have > never grown nice knob). Actually, the more I think about this, the more I think we *do* need a few details on group scheduling. Otherwise, it's difficult to explain to the use why nice(1) no longer works as traditionally expected. Here's my attempt to define the root task group: * If autogrouping is disabled, then all processes in the root CPU cgroup form a scheduling group (sometimes called the "root task group"). Can you improve on this? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline
On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas Färber wrote:
> Found while reviewing Marvell dsa bindings usage.
Hi Andreas
It is good practice to put the maintainer you expect to accept the
patch on the To: line. You have at least two different maintainers on
Cc: so it is currently ambiguous. And these lists can be high volume,
so without a copy in the maintainers inbox, patches can be overlooked.
> Fixes: f283745b3caf ("arm: vf610: zii devel b: Add support for switch
> interrupts")
> Cc: Andrew Lunn
> Cc: David S. Miller
> Signed-off-by: Andreas Färber
Reviewed-by: Andrew Lunn
Andrew
> ---
> arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> index 7ea617e47fe4..958b4c42d320 100644
> --- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> +++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> @@ -153,7 +153,8 @@
> switch0phy1: switch1phy0@1 {
> reg = <1>;
> interrupt-parent = <&switch0>;
> - interrupts = <1
> IRQ_TYPE_LEVEL_HIGH>; };
> + interrupts = <1
> IRQ_TYPE_LEVEL_HIGH>;
> + };
> switch0phy2: switch1phy0@2 {
> reg = <2>;
> interrupt-parent = <&switch0>;
> --
> 2.6.6
>
Re: [PATCH] mv88e6xxx: Fix mv88e6xxx_g1_irq_free() interrupt count
On Sun, Nov 27, 2016 at 09:43:44PM +0100, Andreas Färber wrote:
> mv88e6xxx_g1_irq_setup() sets up chip->g1_irq.nirqs interrupt mappings,
> so free the same amount. This will be 8 or 9 in practice, less than 16.
Hi Andreas
The patch is correct, but please read
Documentation/networking/netdev-FAQ.txt
and then resubmit the patch.
Andrew
>
> Fixes: dc30c35be720 ("net: dsa: mv88e6xxx: Implement interrupt support.")
> Cc: Andrew Lunn
> Signed-off-by: Andreas Färber
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
> b/drivers/net/dsa/mv88e6xxx/chip.c
> index 98302358ceb9..95b9efb33ec7 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -421,7 +421,7 @@ static void mv88e6xxx_g1_irq_free(struct mv88e6xxx_chip
> *chip)
>
> free_irq(chip->irq, chip);
>
> - for (irq = 0; irq < 16; irq++) {
> + for (irq = 0; irq < chip->g1_irq.nirqs; irq++) {
> virq = irq_find_mapping(chip->g1_irq.domain, irq);
> irq_dispose_mapping(virq);
> }
> --
> 2.6.6
>
