* linux-next: manual merge of the char-misc tree with the lightnvm tree
From: Stephen Rothwell @ 2016-11-22 7:29 UTC (permalink / raw)
To: Greg KH, Arnd Bergmann, Matias Bjørling
Cc: linux-next, linux-kernel, Paul Gortmaker, Javier González
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in:
drivers/lightnvm/core.c
between commit:
7b0d392f6957 ("lightnvm: remove sysfs configuration interface")
from the lightnvm tree and commit:
389b2a1c0e90 ("lightnvm: make core.c explicitly non-modular")
from the char-misc tree.
I fixed it up (the former removed the code that was commented by the
latter, so I just removed it) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your
tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
I do wonder why commit 389b2a1c0e90 is in the char-misc tree and not
the lightnvm or block trees?
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the tip tree with the pm tree
From: Stephen Rothwell @ 2016-11-22 5:48 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Borislav Petkov, Len Brown, Wei Yongjun,
Arnd Bergmann
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/idle/Kconfig
drivers/idle/i7300_idle.c
between commits:
f2f31bb3f50b ("idle / i7300: Add CONFIG_PCI dependency")
ccd29e2ed6bc ("i7300_idle: avoid theoretical uninitialized data usage")
881ef1847b2d ("i7300_idle: fix typo in parameter description")
from the pm tree and commit:
b65ce83f2a60 ("i7300_idle: Remove this driver")
from the tip tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the audit tree with Linus' tree
From: Stephen Rothwell @ 2016-11-22 5:29 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-next, linux-kernel, Richard Guy Briggs
Hi Paul,
Today's linux-next merge of the audit tree got a conflict in:
include/uapi/linux/audit.h
between commit:
7ff89ac608d9 ("audit: add exclude filter extension to feature bitmap")
from Linus' tree and commit:
0489410368df ("audit: add support for session ID user filter")
from the audit tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/uapi/linux/audit.h
index 208df7b44e90,c8dc97bc2c1b..000000000000
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@@ -329,11 -330,11 +330,13 @@@ enum
#define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT 0x00000001
#define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x00000002
#define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH 0x00000004
+#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x00000008
+ #define AUDIT_FEATURE_BITMAP_SESSIONID_FILTER 0x00000010
#define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
- AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND)
++ AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND | \
+ AUDIT_FEATURE_BITMAP_SESSIONID_FILTER)
/* deprecated: AUDIT_VERSION_* */
#define AUDIT_VERSION_LATEST AUDIT_FEATURE_BITMAP_ALL
^ permalink raw reply
* Re: linux-next: manual merge of the lightnvm tree with Linus' tree
From: Jens Axboe @ 2016-11-22 4:56 UTC (permalink / raw)
To: Stephen Rothwell, Matias Bjørling; +Cc: linux-next, linux-kernel
In-Reply-To: <20161122145917.4f1d0e86@canb.auug.org.au>
On 11/21/2016 08:59 PM, Stephen Rothwell wrote:
> Hi Matias,
>
> Today's linux-next merge of the lightnvm tree got a conflict in:
>
> drivers/nvme/host/lightnvm.c
>
> between commit:
>
> 409ae5a76e05 ("lightnvm: invalid offset calculation for lba_shift")
>
> from Linus' tree and commit:
>
> 2db3cb58a3dd ("nvme: lightnvm: attach lightnvm sysfs to nvme block device")
>
> from the lightnvm tree.
>
> I fixed it up (I just used the latter version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise
> any particularly complex conflicts.
Matias, you should base your branches on mine to avoid situations like
this. And additionally, submit them for inclusion if they are targeted
at 4.10 (and I'm thinking they are, if they are in linux-next).
--
Jens Axboe
^ permalink raw reply
* linux-next: manual merge of the md tree with the block tree
From: Stephen Rothwell @ 2016-11-22 4:50 UTC (permalink / raw)
To: Shaohua Li, Jens Axboe
Cc: linux-next, linux-kernel, Christoph Hellwig, Song Liu
Hi Shaohua,
Today's linux-next merge of the md tree got a conflict in:
drivers/md/raid5-cache.c
between commit:
70fd76140a6c ("block,fs: use REQ_* flags directly")
from the block tree and commits:
b4c625c67362 ("md/r5cache: r5cache recovery: part 1")
3bddb7f8f264 ("md/r5cache: handle FLUSH and FUA")
from the md tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/md/raid5-cache.c
index 2bca090cd64e,8cb79fc0eed9..000000000000
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@@ -231,6 -544,64 +544,64 @@@ static void r5l_log_endio(struct bio *b
if (log->need_cache_flush)
md_wakeup_thread(log->rdev->mddev->thread);
+
+ if (io->has_null_flush) {
+ struct bio *bi;
+
+ WARN_ON(bio_list_empty(&io->flush_barriers));
+ while ((bi = bio_list_pop(&io->flush_barriers)) != NULL) {
+ bio_endio(bi);
+ atomic_dec(&io->pending_stripe);
+ }
+ if (atomic_read(&io->pending_stripe) == 0)
+ __r5l_stripe_write_finished(io);
+ }
+ }
+
+ static void r5l_do_submit_io(struct r5l_log *log, struct r5l_io_unit *io)
+ {
+ unsigned long flags;
+
+ spin_lock_irqsave(&log->io_list_lock, flags);
+ __r5l_set_io_unit_state(io, IO_UNIT_IO_START);
+ spin_unlock_irqrestore(&log->io_list_lock, flags);
+
+ if (io->has_flush)
- bio_set_op_attrs(io->current_bio, REQ_OP_WRITE, WRITE_FLUSH);
++ io->current_bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH;
+ if (io->has_fua)
- bio_set_op_attrs(io->current_bio, REQ_OP_WRITE, WRITE_FUA);
++ io->current_bio->bi_opf = REQ_OP_WRITE | REQ_FUA;
+ submit_bio(io->current_bio);
+
+ if (!io->split_bio)
+ return;
+
+ if (io->has_flush)
- bio_set_op_attrs(io->split_bio, REQ_OP_WRITE, WRITE_FLUSH);
++ io->split_bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH;
+ if (io->has_fua)
- bio_set_op_attrs(io->split_bio, REQ_OP_WRITE, WRITE_FUA);
++ io->split_bio->bi_opf = REQ_OP_WRITE | REQ_FUA;
+ submit_bio(io->split_bio);
+ }
+
+ /* deferred io_unit will be dispatched here */
+ static void r5l_submit_io_async(struct work_struct *work)
+ {
+ struct r5l_log *log = container_of(work, struct r5l_log,
+ deferred_io_work);
+ struct r5l_io_unit *io = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(&log->io_list_lock, flags);
+ if (!list_empty(&log->running_ios)) {
+ io = list_first_entry(&log->running_ios, struct r5l_io_unit,
+ log_sibling);
+ if (!io->io_deferred)
+ io = NULL;
+ else
+ io->io_deferred = 0;
+ }
+ spin_unlock_irqrestore(&log->io_list_lock, flags);
+ if (io)
+ r5l_do_submit_io(log, io);
}
static void r5l_submit_current_io(struct r5l_log *log)
@@@ -892,82 -1517,138 +1517,138 @@@ static int r5l_recovery_read_meta_block
return 0;
}
- static int r5l_recovery_flush_one_stripe(struct r5l_log *log,
- struct r5l_recovery_ctx *ctx,
- sector_t stripe_sect,
- int *offset, sector_t *log_offset)
+ static void
+ r5l_recovery_create_empty_meta_block(struct r5l_log *log,
+ struct page *page,
+ sector_t pos, u64 seq)
{
- struct r5conf *conf = log->rdev->mddev->private;
- struct stripe_head *sh;
- struct r5l_payload_data_parity *payload;
- int disk_index;
+ struct r5l_meta_block *mb;
+ u32 crc;
- sh = raid5_get_active_stripe(conf, stripe_sect, 0, 0, 0);
- while (1) {
- payload = page_address(ctx->meta_page) + *offset;
+ mb = page_address(page);
+ clear_page(mb);
+ mb->magic = cpu_to_le32(R5LOG_MAGIC);
+ mb->version = R5LOG_VERSION;
+ mb->meta_size = cpu_to_le32(sizeof(struct r5l_meta_block));
+ mb->seq = cpu_to_le64(seq);
+ mb->position = cpu_to_le64(pos);
+ crc = crc32c_le(log->uuid_checksum, mb, PAGE_SIZE);
+ mb->checksum = cpu_to_le32(crc);
+ }
- if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_DATA) {
- raid5_compute_sector(conf,
- le64_to_cpu(payload->location), 0,
- &disk_index, sh);
+ static int r5l_log_write_empty_meta_block(struct r5l_log *log, sector_t pos,
+ u64 seq)
+ {
+ struct page *page;
- sync_page_io(log->rdev, *log_offset, PAGE_SIZE,
- sh->dev[disk_index].page, REQ_OP_READ, 0,
- false);
- sh->dev[disk_index].log_checksum =
- le32_to_cpu(payload->checksum[0]);
- set_bit(R5_Wantwrite, &sh->dev[disk_index].flags);
- ctx->meta_total_blocks += BLOCK_SECTORS;
- } else {
- disk_index = sh->pd_idx;
- sync_page_io(log->rdev, *log_offset, PAGE_SIZE,
- sh->dev[disk_index].page, REQ_OP_READ, 0,
- false);
- sh->dev[disk_index].log_checksum =
- le32_to_cpu(payload->checksum[0]);
- set_bit(R5_Wantwrite, &sh->dev[disk_index].flags);
-
- if (sh->qd_idx >= 0) {
- disk_index = sh->qd_idx;
- sync_page_io(log->rdev,
- r5l_ring_add(log, *log_offset, BLOCK_SECTORS),
- PAGE_SIZE, sh->dev[disk_index].page,
- REQ_OP_READ, 0, false);
- sh->dev[disk_index].log_checksum =
- le32_to_cpu(payload->checksum[1]);
- set_bit(R5_Wantwrite,
- &sh->dev[disk_index].flags);
- }
- ctx->meta_total_blocks += BLOCK_SECTORS * conf->max_degraded;
- }
+ page = alloc_page(GFP_KERNEL);
+ if (!page)
+ return -ENOMEM;
+ r5l_recovery_create_empty_meta_block(log, page, pos, seq);
+ if (!sync_page_io(log->rdev, pos, PAGE_SIZE, page, REQ_OP_WRITE,
- WRITE_FUA, false)) {
++ REQ_FUA, false)) {
+ __free_page(page);
+ return -EIO;
+ }
+ __free_page(page);
+ return 0;
+ }
- *log_offset = r5l_ring_add(log, *log_offset,
- le32_to_cpu(payload->size));
- *offset += sizeof(struct r5l_payload_data_parity) +
- sizeof(__le32) *
- (le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
- if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_PARITY)
- break;
+ /*
+ * r5l_recovery_load_data and r5l_recovery_load_parity uses flag R5_Wantwrite
+ * to mark valid (potentially not flushed) data in the journal.
+ *
+ * We already verified checksum in r5l_recovery_verify_data_checksum_for_mb,
+ * so there should not be any mismatch here.
+ */
+ static void r5l_recovery_load_data(struct r5l_log *log,
+ struct stripe_head *sh,
+ struct r5l_recovery_ctx *ctx,
+ struct r5l_payload_data_parity *payload,
+ sector_t log_offset)
+ {
+ struct mddev *mddev = log->rdev->mddev;
+ struct r5conf *conf = mddev->private;
+ int dd_idx;
+
+ raid5_compute_sector(conf,
+ le64_to_cpu(payload->location), 0,
+ &dd_idx, sh);
+ sync_page_io(log->rdev, log_offset, PAGE_SIZE,
+ sh->dev[dd_idx].page, REQ_OP_READ, 0, false);
+ sh->dev[dd_idx].log_checksum =
+ le32_to_cpu(payload->checksum[0]);
+ ctx->meta_total_blocks += BLOCK_SECTORS;
+
+ set_bit(R5_Wantwrite, &sh->dev[dd_idx].flags);
+ set_bit(STRIPE_R5C_CACHING, &sh->state);
+ }
+
+ static void r5l_recovery_load_parity(struct r5l_log *log,
+ struct stripe_head *sh,
+ struct r5l_recovery_ctx *ctx,
+ struct r5l_payload_data_parity *payload,
+ sector_t log_offset)
+ {
+ struct mddev *mddev = log->rdev->mddev;
+ struct r5conf *conf = mddev->private;
+
+ ctx->meta_total_blocks += BLOCK_SECTORS * conf->max_degraded;
+ sync_page_io(log->rdev, log_offset, PAGE_SIZE,
+ sh->dev[sh->pd_idx].page, REQ_OP_READ, 0, false);
+ sh->dev[sh->pd_idx].log_checksum =
+ le32_to_cpu(payload->checksum[0]);
+ set_bit(R5_Wantwrite, &sh->dev[sh->pd_idx].flags);
+
+ if (sh->qd_idx >= 0) {
+ sync_page_io(log->rdev,
+ r5l_ring_add(log, log_offset, BLOCK_SECTORS),
+ PAGE_SIZE, sh->dev[sh->qd_idx].page,
+ REQ_OP_READ, 0, false);
+ sh->dev[sh->qd_idx].log_checksum =
+ le32_to_cpu(payload->checksum[1]);
+ set_bit(R5_Wantwrite, &sh->dev[sh->qd_idx].flags);
}
+ clear_bit(STRIPE_R5C_CACHING, &sh->state);
+ }
- for (disk_index = 0; disk_index < sh->disks; disk_index++) {
- void *addr;
- u32 checksum;
+ static void r5l_recovery_reset_stripe(struct stripe_head *sh)
+ {
+ int i;
+ sh->state = 0;
+ sh->log_start = MaxSector;
+ for (i = sh->disks; i--; )
+ sh->dev[i].flags = 0;
+ }
+
+ static void
+ r5l_recovery_replay_one_stripe(struct r5conf *conf,
+ struct stripe_head *sh,
+ struct r5l_recovery_ctx *ctx)
+ {
+ struct md_rdev *rdev, *rrdev;
+ int disk_index;
+ int data_count = 0;
+
+ for (disk_index = 0; disk_index < sh->disks; disk_index++) {
if (!test_bit(R5_Wantwrite, &sh->dev[disk_index].flags))
continue;
- addr = kmap_atomic(sh->dev[disk_index].page);
- checksum = crc32c_le(log->uuid_checksum, addr, PAGE_SIZE);
- kunmap_atomic(addr);
- if (checksum != sh->dev[disk_index].log_checksum)
- goto error;
+ if (disk_index == sh->qd_idx || disk_index == sh->pd_idx)
+ continue;
+ data_count++;
}
- for (disk_index = 0; disk_index < sh->disks; disk_index++) {
- struct md_rdev *rdev, *rrdev;
+ /*
+ * stripes that only have parity must have been flushed
+ * before the crash that we are now recovering from, so
+ * there is nothing more to recovery.
+ */
+ if (data_count == 0)
+ goto out;
- if (!test_and_clear_bit(R5_Wantwrite,
- &sh->dev[disk_index].flags))
+ for (disk_index = 0; disk_index < sh->disks; disk_index++) {
+ if (!test_bit(R5_Wantwrite, &sh->dev[disk_index].flags))
continue;
/* in case device is broken */
@@@ -1031,31 -1981,158 +1981,158 @@@ static int r5c_recovery_flush_log(struc
ctx->seq++;
ctx->pos = r5l_ring_add(log, ctx->pos, ctx->meta_total_blocks);
}
+
+ if (ret == -ENOMEM) {
+ r5c_recovery_drop_stripes(&ctx->cached_list, ctx);
+ return ret;
+ }
+
+ /* replay data-parity stripes */
+ r5c_recovery_replay_stripes(&ctx->cached_list, ctx);
+
+ /* load data-only stripes to stripe cache */
+ list_for_each_entry_safe(sh, next, &ctx->cached_list, lru) {
+ WARN_ON(!test_bit(STRIPE_R5C_CACHING, &sh->state));
+ r5c_recovery_load_one_stripe(log, sh);
+ list_del_init(&sh->lru);
+ raid5_release_stripe(sh);
+ ctx->data_only_stripes++;
+ }
+
+ return 0;
}
- static int r5l_log_write_empty_meta_block(struct r5l_log *log, sector_t pos,
- u64 seq)
+ /*
+ * we did a recovery. Now ctx.pos points to an invalid meta block. New
+ * log will start here. but we can't let superblock point to last valid
+ * meta block. The log might looks like:
+ * | meta 1| meta 2| meta 3|
+ * meta 1 is valid, meta 2 is invalid. meta 3 could be valid. If
+ * superblock points to meta 1, we write a new valid meta 2n. if crash
+ * happens again, new recovery will start from meta 1. Since meta 2n is
+ * valid now, recovery will think meta 3 is valid, which is wrong.
+ * The solution is we create a new meta in meta2 with its seq == meta
+ * 1's seq + 10 and let superblock points to meta2. The same recovery will
+ * not think meta 3 is a valid meta, because its seq doesn't match
+ */
+
+ /*
+ * Before recovery, the log looks like the following
+ *
+ * ---------------------------------------------
+ * | valid log | invalid log |
+ * ---------------------------------------------
+ * ^
+ * |- log->last_checkpoint
+ * |- log->last_cp_seq
+ *
+ * Now we scan through the log until we see invalid entry
+ *
+ * ---------------------------------------------
+ * | valid log | invalid log |
+ * ---------------------------------------------
+ * ^ ^
+ * |- log->last_checkpoint |- ctx->pos
+ * |- log->last_cp_seq |- ctx->seq
+ *
+ * From this point, we need to increase seq number by 10 to avoid
+ * confusing next recovery.
+ *
+ * ---------------------------------------------
+ * | valid log | invalid log |
+ * ---------------------------------------------
+ * ^ ^
+ * |- log->last_checkpoint |- ctx->pos+1
+ * |- log->last_cp_seq |- ctx->seq+11
+ *
+ * However, it is not safe to start the state machine yet, because data only
+ * parities are not yet secured in RAID. To save these data only parities, we
+ * rewrite them from seq+11.
+ *
+ * -----------------------------------------------------------------
+ * | valid log | data only stripes | invalid log |
+ * -----------------------------------------------------------------
+ * ^ ^
+ * |- log->last_checkpoint |- ctx->pos+n
+ * |- log->last_cp_seq |- ctx->seq+10+n
+ *
+ * If failure happens again during this process, the recovery can safe start
+ * again from log->last_checkpoint.
+ *
+ * Once data only stripes are rewritten to journal, we move log_tail
+ *
+ * -----------------------------------------------------------------
+ * | old log | data only stripes | invalid log |
+ * -----------------------------------------------------------------
+ * ^ ^
+ * |- log->last_checkpoint |- ctx->pos+n
+ * |- log->last_cp_seq |- ctx->seq+10+n
+ *
+ * Then we can safely start the state machine. If failure happens from this
+ * point on, the recovery will start from new log->last_checkpoint.
+ */
+ static int
+ r5c_recovery_rewrite_data_only_stripes(struct r5l_log *log,
+ struct r5l_recovery_ctx *ctx)
{
+ struct stripe_head *sh;
+ struct mddev *mddev = log->rdev->mddev;
struct page *page;
- struct r5l_meta_block *mb;
- u32 crc;
- page = alloc_page(GFP_KERNEL | __GFP_ZERO);
- if (!page)
+ page = alloc_page(GFP_KERNEL);
+ if (!page) {
+ pr_err("md/raid:%s: cannot allocate memory to rewrite data only stripes\n",
+ mdname(mddev));
return -ENOMEM;
- mb = page_address(page);
- mb->magic = cpu_to_le32(R5LOG_MAGIC);
- mb->version = R5LOG_VERSION;
- mb->meta_size = cpu_to_le32(sizeof(struct r5l_meta_block));
- mb->seq = cpu_to_le64(seq);
- mb->position = cpu_to_le64(pos);
- crc = crc32c_le(log->uuid_checksum, mb, PAGE_SIZE);
- mb->checksum = cpu_to_le32(crc);
+ }
- if (!sync_page_io(log->rdev, pos, PAGE_SIZE, page, REQ_OP_WRITE,
- REQ_FUA, false)) {
- __free_page(page);
- return -EIO;
+ ctx->seq += 10;
+ list_for_each_entry(sh, &ctx->cached_list, lru) {
+ struct r5l_meta_block *mb;
+ int i;
+ int offset;
+ sector_t write_pos;
+
+ WARN_ON(!test_bit(STRIPE_R5C_CACHING, &sh->state));
+ r5l_recovery_create_empty_meta_block(log, page,
+ ctx->pos, ctx->seq);
+ mb = page_address(page);
+ offset = le32_to_cpu(mb->meta_size);
+ write_pos = ctx->pos + BLOCK_SECTORS;
+
+ for (i = sh->disks; i--; ) {
+ struct r5dev *dev = &sh->dev[i];
+ struct r5l_payload_data_parity *payload;
+ void *addr;
+
+ if (test_bit(R5_InJournal, &dev->flags)) {
+ payload = (void *)mb + offset;
+ payload->header.type = cpu_to_le16(
+ R5LOG_PAYLOAD_DATA);
+ payload->size = BLOCK_SECTORS;
+ payload->location = cpu_to_le64(
+ raid5_compute_blocknr(sh, i, 0));
+ addr = kmap_atomic(dev->page);
+ payload->checksum[0] = cpu_to_le32(
+ crc32c_le(log->uuid_checksum, addr,
+ PAGE_SIZE));
+ kunmap_atomic(addr);
+ sync_page_io(log->rdev, write_pos, PAGE_SIZE,
+ dev->page, REQ_OP_WRITE, 0, false);
+ write_pos = r5l_ring_add(log, write_pos,
+ BLOCK_SECTORS);
+ offset += sizeof(__le32) +
+ sizeof(struct r5l_payload_data_parity);
+
+ }
+ }
+ mb->meta_size = cpu_to_le32(offset);
+ mb->checksum = crc32c_le(log->uuid_checksum, mb, PAGE_SIZE);
+ sync_page_io(log->rdev, ctx->pos, PAGE_SIZE, page,
- REQ_OP_WRITE, WRITE_FUA, false);
++ REQ_OP_WRITE, REQ_FUA, false);
+ sh->log_start = ctx->pos;
+ ctx->pos = write_pos;
+ ctx->seq += 1;
}
__free_page(page);
return 0;
^ permalink raw reply
* linux-next: manual merge of the lightnvm tree with Linus' tree
From: Stephen Rothwell @ 2016-11-22 3:59 UTC (permalink / raw)
To: Matias Bjørling; +Cc: linux-next, linux-kernel, Jens Axboe
Hi Matias,
Today's linux-next merge of the lightnvm tree got a conflict in:
drivers/nvme/host/lightnvm.c
between commit:
409ae5a76e05 ("lightnvm: invalid offset calculation for lba_shift")
from Linus' tree and commit:
2db3cb58a3dd ("nvme: lightnvm: attach lightnvm sysfs to nvme block device")
from the lightnvm tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise
any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the block tree with the f2fs tree
From: Stephen Rothwell @ 2016-11-22 3:42 UTC (permalink / raw)
To: Jens Axboe, Jaegeuk Kim; +Cc: linux-next, linux-kernel, Christoph Hellwig
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
fs/f2fs/segment.c
between commit:
792b84b74b54 ("f2fs: support multiple devices")
from the f2fs tree and commit:
70fd76140a6c ("block,fs: use REQ_* flags directly")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/f2fs/segment.c
index eaa0b40e1ba0,f1b4a1775ebe..000000000000
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@@ -401,33 -400,6 +401,33 @@@ void f2fs_balance_fs_bg(struct f2fs_sb_
}
}
+static int __submit_flush_wait(struct block_device *bdev)
+{
+ struct bio *bio = f2fs_bio_alloc(0);
+ int ret;
+
- bio_set_op_attrs(bio, REQ_OP_WRITE, WRITE_FLUSH);
++ bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH;
+ bio->bi_bdev = bdev;
+ ret = submit_bio_wait(bio);
+ bio_put(bio);
+ return ret;
+}
+
+static int submit_flush_wait(struct f2fs_sb_info *sbi)
+{
+ int ret = __submit_flush_wait(sbi->sb->s_bdev);
+ int i;
+
+ if (sbi->s_ndevs && !ret) {
+ for (i = 1; i < sbi->s_ndevs; i++) {
+ ret = __submit_flush_wait(FDEV(i).bdev);
+ if (ret)
+ break;
+ }
+ }
+ return ret;
+}
+
static int issue_flush_thread(void *data)
{
struct f2fs_sb_info *sbi = data;
^ permalink raw reply
* linux-next: build warning after merge of the drm-misc tree
From: Stephen Rothwell @ 2016-11-22 1:45 UTC (permalink / raw)
To: Daniel Vetter, Intel Graphics, DRI
Cc: linux-next, linux-kernel, Bjorn Helgaas
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from include/linux/pci.h:30:0,
from drivers/gpu/vga/vgaarb.c:40:
drivers/gpu/vga/vgaarb.c: In function 'vga_arb_device_init':
include/linux/device.h:1214:36: warning: 'dev' may be used uninitialized in this function [-Wmaybe-uninitialized]
#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
^
drivers/gpu/vga/vgaarb.c:1410:17: note: 'dev' was declared here
struct device *dev;
^
Introduced by commit
a75d68f62106 ("vgaarb: Use dev_printk() when possible")
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the drm tree with the arm tree
From: Stephen Rothwell @ 2016-11-22 1:34 UTC (permalink / raw)
To: Dave Airlie, Russell King
Cc: linux-next, linux-kernel, Baoyou Xie, Daniel Vetter
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i2c/tda998x_drv.c
between commit:
ad975f9364a3 ("drm/i2c: tda998x: group audio functions together")
from the arm tree and commit:
c20ea8fd4986 ("drm/i2c/tda998x: mark symbol static where possible")
from the drm tree.
I fixed it up (see below - it is much simpler than it appears) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i2c/tda998x_drv.c
index 86f47e190309,027521f30b6e..000000000000
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@@ -838,164 -819,269 +838,165 @@@ tda998x_configure_audio(struct tda998x_
return tda998x_write_aif(priv, ¶ms->cea);
}
-/* DRM encoder functions */
-
-static void tda998x_encoder_set_config(struct tda998x_priv *priv,
- const struct tda998x_encoder_params *p)
-{
- priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(p->swap_a) |
- (p->mirr_a ? VIP_CNTRL_0_MIRR_A : 0) |
- VIP_CNTRL_0_SWAP_B(p->swap_b) |
- (p->mirr_b ? VIP_CNTRL_0_MIRR_B : 0);
- priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(p->swap_c) |
- (p->mirr_c ? VIP_CNTRL_1_MIRR_C : 0) |
- VIP_CNTRL_1_SWAP_D(p->swap_d) |
- (p->mirr_d ? VIP_CNTRL_1_MIRR_D : 0);
- priv->vip_cntrl_2 = VIP_CNTRL_2_SWAP_E(p->swap_e) |
- (p->mirr_e ? VIP_CNTRL_2_MIRR_E : 0) |
- VIP_CNTRL_2_SWAP_F(p->swap_f) |
- (p->mirr_f ? VIP_CNTRL_2_MIRR_F : 0);
-
- priv->audio_params = p->audio_params;
-}
-
-static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
+static int tda998x_audio_hw_params(struct device *dev, void *data,
+ struct hdmi_codec_daifmt *daifmt,
+ struct hdmi_codec_params *params)
{
- struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
-
- /* we only care about on or off: */
- if (mode != DRM_MODE_DPMS_ON)
- mode = DRM_MODE_DPMS_OFF;
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
+ int i, ret;
+ struct tda998x_audio_params audio = {
+ .sample_width = params->sample_width,
+ .sample_rate = params->sample_rate,
+ .cea = params->cea,
+ };
- if (mode == priv->dpms)
- return;
+ memcpy(audio.status, params->iec.status,
+ min(sizeof(audio.status), sizeof(params->iec.status)));
- switch (mode) {
- case DRM_MODE_DPMS_ON:
- /* enable video ports, audio will be enabled later */
- reg_write(priv, REG_ENA_VP_0, 0xff);
- reg_write(priv, REG_ENA_VP_1, 0xff);
- reg_write(priv, REG_ENA_VP_2, 0xff);
- /* set muxing after enabling ports: */
- reg_write(priv, REG_VIP_CNTRL_0, priv->vip_cntrl_0);
- reg_write(priv, REG_VIP_CNTRL_1, priv->vip_cntrl_1);
- reg_write(priv, REG_VIP_CNTRL_2, priv->vip_cntrl_2);
+ switch (daifmt->fmt) {
+ case HDMI_I2S:
+ if (daifmt->bit_clk_inv || daifmt->frame_clk_inv ||
+ daifmt->bit_clk_master || daifmt->frame_clk_master) {
+ dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__,
+ daifmt->bit_clk_inv, daifmt->frame_clk_inv,
+ daifmt->bit_clk_master,
+ daifmt->frame_clk_master);
+ return -EINVAL;
+ }
+ for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
+ if (priv->audio_port[i].format == AFMT_I2S)
+ audio.config = priv->audio_port[i].config;
+ audio.format = AFMT_I2S;
break;
- case DRM_MODE_DPMS_OFF:
- /* disable video ports */
- reg_write(priv, REG_ENA_VP_0, 0x00);
- reg_write(priv, REG_ENA_VP_1, 0x00);
- reg_write(priv, REG_ENA_VP_2, 0x00);
+ case HDMI_SPDIF:
+ for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
+ if (priv->audio_port[i].format == AFMT_SPDIF)
+ audio.config = priv->audio_port[i].config;
+ audio.format = AFMT_SPDIF;
break;
+ default:
+ dev_err(dev, "%s: Invalid format %d\n", __func__, daifmt->fmt);
+ return -EINVAL;
}
- priv->dpms = mode;
-}
+ if (audio.config == 0) {
+ dev_err(dev, "%s: No audio configuration found\n", __func__);
+ return -EINVAL;
+ }
-static int tda998x_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- /* TDA19988 dotclock can go up to 165MHz */
- struct tda998x_priv *priv = conn_to_tda998x_priv(connector);
+ mutex_lock(&priv->audio_mutex);
+ if (priv->supports_infoframes && priv->sink_has_audio)
+ ret = tda998x_configure_audio(priv, &audio);
+ else
+ ret = 0;
- if (mode->clock > ((priv->rev == TDA19988) ? 165000 : 150000))
- return MODE_CLOCK_HIGH;
- if (mode->htotal >= BIT(13))
- return MODE_BAD_HVALUE;
- if (mode->vtotal >= BIT(11))
- return MODE_BAD_VVALUE;
- return MODE_OK;
+ if (ret == 0)
+ priv->audio_params = audio;
+ mutex_unlock(&priv->audio_mutex);
+
+ return ret;
}
-static void
-tda998x_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+static void tda998x_audio_shutdown(struct device *dev, void *data)
{
- struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
- u16 ref_pix, ref_line, n_pix, n_line;
- u16 hs_pix_s, hs_pix_e;
- u16 vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
- u16 vs2_pix_s, vs2_pix_e, vs2_line_s, vs2_line_e;
- u16 vwin1_line_s, vwin1_line_e;
- u16 vwin2_line_s, vwin2_line_e;
- u16 de_pix_s, de_pix_e;
- u8 reg, div, rep;
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
- /*
- * Internally TDA998x is using ITU-R BT.656 style sync but
- * we get VESA style sync. TDA998x is using a reference pixel
- * relative to ITU to sync to the input frame and for output
- * sync generation. Currently, we are using reference detection
- * from HS/VS, i.e. REFPIX/REFLINE denote frame start sync point
- * which is position of rising VS with coincident rising HS.
- *
- * Now there is some issues to take care of:
- * - HDMI data islands require sync-before-active
- * - TDA998x register values must be > 0 to be enabled
- * - REFLINE needs an additional offset of +1
- * - REFPIX needs an addtional offset of +1 for UYUV and +3 for RGB
- *
- * So we add +1 to all horizontal and vertical register values,
- * plus an additional +3 for REFPIX as we are using RGB input only.
- */
- n_pix = mode->htotal;
- n_line = mode->vtotal;
+ mutex_lock(&priv->audio_mutex);
- hs_pix_e = mode->hsync_end - mode->hdisplay;
- hs_pix_s = mode->hsync_start - mode->hdisplay;
- de_pix_e = mode->htotal;
- de_pix_s = mode->htotal - mode->hdisplay;
- ref_pix = 3 + hs_pix_s;
+ reg_write(priv, REG_ENA_AP, 0);
- /*
- * Attached LCD controllers may generate broken sync. Allow
- * those to adjust the position of the rising VS edge by adding
- * HSKEW to ref_pix.
- */
- if (adjusted_mode->flags & DRM_MODE_FLAG_HSKEW)
- ref_pix += adjusted_mode->hskew;
+ priv->audio_params.format = AFMT_UNUSED;
- if ((mode->flags & DRM_MODE_FLAG_INTERLACE) == 0) {
- ref_line = 1 + mode->vsync_start - mode->vdisplay;
- vwin1_line_s = mode->vtotal - mode->vdisplay - 1;
- vwin1_line_e = vwin1_line_s + mode->vdisplay;
- vs1_pix_s = vs1_pix_e = hs_pix_s;
- vs1_line_s = mode->vsync_start - mode->vdisplay;
- vs1_line_e = vs1_line_s +
- mode->vsync_end - mode->vsync_start;
- vwin2_line_s = vwin2_line_e = 0;
- vs2_pix_s = vs2_pix_e = 0;
- vs2_line_s = vs2_line_e = 0;
- } else {
- ref_line = 1 + (mode->vsync_start - mode->vdisplay)/2;
- vwin1_line_s = (mode->vtotal - mode->vdisplay)/2;
- vwin1_line_e = vwin1_line_s + mode->vdisplay/2;
- vs1_pix_s = vs1_pix_e = hs_pix_s;
- vs1_line_s = (mode->vsync_start - mode->vdisplay)/2;
- vs1_line_e = vs1_line_s +
- (mode->vsync_end - mode->vsync_start)/2;
- vwin2_line_s = vwin1_line_s + mode->vtotal/2;
- vwin2_line_e = vwin2_line_s + mode->vdisplay/2;
- vs2_pix_s = vs2_pix_e = hs_pix_s + mode->htotal/2;
- vs2_line_s = vs1_line_s + mode->vtotal/2 ;
- vs2_line_e = vs2_line_s +
- (mode->vsync_end - mode->vsync_start)/2;
- }
+ mutex_unlock(&priv->audio_mutex);
+}
- int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
- div = 148500 / mode->clock;
- if (div != 0) {
- div--;
- if (div > 3)
- div = 3;
- }
++static int
++tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
- /* mute the audio FIFO: */
- reg_set(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_FIFO);
+ mutex_lock(&priv->audio_mutex);
- /* set HDMI HDCP mode off: */
- reg_write(priv, REG_TBG_CNTRL_1, TBG_CNTRL_1_DWIN_DIS);
- reg_clear(priv, REG_TX33, TX33_HDMI);
- reg_write(priv, REG_ENC_CNTRL, ENC_CNTRL_CTL_CODE(0));
+ tda998x_audio_mute(priv, enable);
- /* no pre-filter or interpolator: */
- reg_write(priv, REG_HVF_CNTRL_0, HVF_CNTRL_0_PREFIL(0) |
- HVF_CNTRL_0_INTPOL(0));
- reg_write(priv, REG_VIP_CNTRL_5, VIP_CNTRL_5_SP_CNT(0));
- reg_write(priv, REG_VIP_CNTRL_4, VIP_CNTRL_4_BLANKIT(0) |
- VIP_CNTRL_4_BLC(0));
+ mutex_unlock(&priv->audio_mutex);
+ return 0;
+}
- reg_clear(priv, REG_PLL_SERIAL_1, PLL_SERIAL_1_SRL_MAN_IZ);
- reg_clear(priv, REG_PLL_SERIAL_3, PLL_SERIAL_3_SRL_CCIR |
- PLL_SERIAL_3_SRL_DE);
- reg_write(priv, REG_SERIALIZER, 0);
- reg_write(priv, REG_HVF_CNTRL_1, HVF_CNTRL_1_VQR(0));
+static int tda998x_audio_get_eld(struct device *dev, void *data,
+ uint8_t *buf, size_t len)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
- /* TODO enable pixel repeat for pixel rates less than 25Msamp/s */
- rep = 0;
- reg_write(priv, REG_RPT_CNTRL, 0);
- reg_write(priv, REG_SEL_CLK, SEL_CLK_SEL_VRF_CLK(0) |
- SEL_CLK_SEL_CLK1 | SEL_CLK_ENA_SC_CLK);
+ mutex_lock(&priv->audio_mutex);
+ memcpy(buf, priv->connector.eld,
+ min(sizeof(priv->connector.eld), len));
+ mutex_unlock(&priv->audio_mutex);
- reg_write(priv, REG_PLL_SERIAL_2, PLL_SERIAL_2_SRL_NOSC(div) |
- PLL_SERIAL_2_SRL_PR(rep));
+ return 0;
+}
- /* set color matrix bypass flag: */
- reg_write(priv, REG_MAT_CONTRL, MAT_CONTRL_MAT_BP |
- MAT_CONTRL_MAT_SC(1));
+static const struct hdmi_codec_ops audio_codec_ops = {
+ .hw_params = tda998x_audio_hw_params,
+ .audio_shutdown = tda998x_audio_shutdown,
+ .digital_mute = tda998x_audio_digital_mute,
+ .get_eld = tda998x_audio_get_eld,
+};
- /* set BIAS tmds value: */
- reg_write(priv, REG_ANA_GENERAL, 0x09);
+static int tda998x_audio_codec_init(struct tda998x_priv *priv,
+ struct device *dev)
+{
+ struct hdmi_codec_pdata codec_data = {
+ .ops = &audio_codec_ops,
+ .max_i2s_channels = 2,
+ };
+ int i;
- /*
- * Sync on rising HSYNC/VSYNC
- */
- reg = VIP_CNTRL_3_SYNC_HS;
+ for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++) {
+ if (priv->audio_port[i].format == AFMT_I2S &&
+ priv->audio_port[i].config != 0)
+ codec_data.i2s = 1;
+ if (priv->audio_port[i].format == AFMT_SPDIF &&
+ priv->audio_port[i].config != 0)
+ codec_data.spdif = 1;
+ }
- /*
- * TDA19988 requires high-active sync at input stage,
- * so invert low-active sync provided by master encoder here
- */
- if (mode->flags & DRM_MODE_FLAG_NHSYNC)
- reg |= VIP_CNTRL_3_H_TGL;
- if (mode->flags & DRM_MODE_FLAG_NVSYNC)
- reg |= VIP_CNTRL_3_V_TGL;
- reg_write(priv, REG_VIP_CNTRL_3, reg);
+ priv->audio_pdev = platform_device_register_data(
+ dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO,
+ &codec_data, sizeof(codec_data));
- reg_write(priv, REG_VIDFORMAT, 0x00);
- reg_write16(priv, REG_REFPIX_MSB, ref_pix);
- reg_write16(priv, REG_REFLINE_MSB, ref_line);
- reg_write16(priv, REG_NPIX_MSB, n_pix);
- reg_write16(priv, REG_NLINE_MSB, n_line);
- reg_write16(priv, REG_VS_LINE_STRT_1_MSB, vs1_line_s);
- reg_write16(priv, REG_VS_PIX_STRT_1_MSB, vs1_pix_s);
- reg_write16(priv, REG_VS_LINE_END_1_MSB, vs1_line_e);
- reg_write16(priv, REG_VS_PIX_END_1_MSB, vs1_pix_e);
- reg_write16(priv, REG_VS_LINE_STRT_2_MSB, vs2_line_s);
- reg_write16(priv, REG_VS_PIX_STRT_2_MSB, vs2_pix_s);
- reg_write16(priv, REG_VS_LINE_END_2_MSB, vs2_line_e);
- reg_write16(priv, REG_VS_PIX_END_2_MSB, vs2_pix_e);
- reg_write16(priv, REG_HS_PIX_START_MSB, hs_pix_s);
- reg_write16(priv, REG_HS_PIX_STOP_MSB, hs_pix_e);
- reg_write16(priv, REG_VWIN_START_1_MSB, vwin1_line_s);
- reg_write16(priv, REG_VWIN_END_1_MSB, vwin1_line_e);
- reg_write16(priv, REG_VWIN_START_2_MSB, vwin2_line_s);
- reg_write16(priv, REG_VWIN_END_2_MSB, vwin2_line_e);
- reg_write16(priv, REG_DE_START_MSB, de_pix_s);
- reg_write16(priv, REG_DE_STOP_MSB, de_pix_e);
+ return PTR_ERR_OR_ZERO(priv->audio_pdev);
+}
- if (priv->rev == TDA19988) {
- /* let incoming pixels fill the active space (if any) */
- reg_write(priv, REG_ENABLE_SPACE, 0x00);
- }
+/* DRM connector functions */
- /*
- * Always generate sync polarity relative to input sync and
- * revert input stage toggled sync at output stage
- */
- reg = TBG_CNTRL_1_DWIN_DIS | TBG_CNTRL_1_TGL_EN;
- if (mode->flags & DRM_MODE_FLAG_NHSYNC)
- reg |= TBG_CNTRL_1_H_TGL;
- if (mode->flags & DRM_MODE_FLAG_NVSYNC)
- reg |= TBG_CNTRL_1_V_TGL;
- reg_write(priv, REG_TBG_CNTRL_1, reg);
+static int tda998x_connector_dpms(struct drm_connector *connector, int mode)
+{
+ if (drm_core_check_feature(connector->dev, DRIVER_ATOMIC))
+ return drm_atomic_helper_connector_dpms(connector, mode);
+ else
+ return drm_helper_connector_dpms(connector, mode);
+}
- /* must be last register set: */
- reg_write(priv, REG_TBG_CNTRL_0, 0);
+static int tda998x_connector_fill_modes(struct drm_connector *connector,
+ uint32_t maxX, uint32_t maxY)
+{
+ struct tda998x_priv *priv = conn_to_tda998x_priv(connector);
+ int ret;
- /* Only setup the info frames if the sink is HDMI */
- if (priv->is_hdmi_sink) {
- /* We need to turn HDMI HDCP stuff on to get audio through */
- reg &= ~TBG_CNTRL_1_DWIN_DIS;
- reg_write(priv, REG_TBG_CNTRL_1, reg);
- reg_write(priv, REG_ENC_CNTRL, ENC_CNTRL_CTL_CODE(1));
- reg_set(priv, REG_TX33, TX33_HDMI);
+ mutex_lock(&priv->audio_mutex);
+ ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
- tda998x_write_avi(priv, adjusted_mode);
+ if (connector->edid_blob_ptr) {
+ struct edid *edid = (void *)connector->edid_blob_ptr->data;
- if (priv->audio_params.format != AFMT_UNUSED) {
- mutex_lock(&priv->audio_mutex);
- tda998x_configure_audio(priv,
- &priv->audio_params,
- adjusted_mode->clock);
- mutex_unlock(&priv->audio_mutex);
- }
+ priv->sink_has_audio = drm_detect_monitor_audio(edid);
+ } else {
+ priv->sink_has_audio = false;
}
+ mutex_unlock(&priv->audio_mutex);
+
+ return ret;
}
static enum drm_connector_status
^ permalink raw reply
* Re: linux-next: build warnings after merge of the net-next tree
From: Florian Fainelli @ 2016-11-22 1:28 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking
Cc: linux-next, linux-kernel, Thomas Petazzoni, Gregory Clement
In-Reply-To: <20161122122216.575b1793@canb.auug.org.au>
+Thomas, Gregory,
On 11/21/2016 05:22 PM, Stephen Rothwell wrote:
[snip]
>
> Introduced by commit
>
> a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST")
>
> "a few warnings" is a matter of perception. :-(
Thomas, based on our IRC conversation, do you already have patches for
mvneta and mvpp2 to build without warning on 64-bit or should I prepare
patches for these?
--
Florian
^ permalink raw reply
* linux-next: build warnings after merge of the net-next tree
From: Stephen Rothwell @ 2016-11-22 1:22 UTC (permalink / raw)
To: David Miller, Networking; +Cc: Florian Fainelli, linux-next, linux-kernel
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_construct':
drivers/net/ethernet/marvell/mvneta_bm.c:103:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
*(u32 *)buf = (u32)buf;
^
In file included from include/linux/clk.h:16:0,
from drivers/net/ethernet/marvell/mvneta_bm.c:13:
drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_pool_create':
drivers/net/ethernet/marvell/mvneta_bm.c:128:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVNETA_BM_POOL_PTR_ALIGN)) {
^
include/linux/kernel.h:51:30: note: in definition of macro 'IS_ALIGNED'
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
^
drivers/net/ethernet/marvell/mvneta_bm.c:128:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVNETA_BM_POOL_PTR_ALIGN)) {
^
include/linux/kernel.h:51:44: note: in definition of macro 'IS_ALIGNED'
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
^
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_rx_refill':
drivers/net/ethernet/marvell/mvneta.c:1802:42: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
mvneta_rx_desc_fill(rx_desc, phys_addr, (u32)data);
^
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_rxq_drop_pkts':
drivers/net/ethernet/marvell/mvneta.c:1864:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
void *data = (void *)rx_desc->buf_cookie;
^
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_rx_swbm':
drivers/net/ethernet/marvell/mvneta.c:1902:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
data = (unsigned char *)rx_desc->buf_cookie;
^
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_rx_hwbm':
drivers/net/ethernet/marvell/mvneta.c:2023:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
data = (unsigned char *)rx_desc->buf_cookie;
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_mac_promisc_set':
drivers/net/ethernet/marvell/mvpp2.c:524:33: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L2_UCAST ~(BIT(9) | BIT(10))
^
drivers/net/ethernet/marvell/mvpp2.c:1459:33: note: in expansion of macro 'MVPP2_PRS_RI_L2_UCAST'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L2_UCAST,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_dsa_tag_set':
drivers/net/ethernet/marvell/mvpp2.c:517:34: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_VLAN_NONE ~(BIT(2) | BIT(3))
^
drivers/net/ethernet/marvell/mvpp2.c:1572:34: note: in expansion of macro 'MVPP2_PRS_RI_VLAN_NONE'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_VLAN_NONE,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_dsa_tag_ethertype_set':
drivers/net/ethernet/marvell/mvpp2.c:517:34: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_VLAN_NONE ~(BIT(2) | BIT(3))
^
drivers/net/ethernet/marvell/mvpp2.c:1642:34: note: in expansion of macro 'MVPP2_PRS_RI_VLAN_NONE'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_VLAN_NONE,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_etype_init':
drivers/net/ethernet/marvell/mvpp2.c:529:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UN ~(BIT(12) | BIT(13) | BIT(14))
^
drivers/net/ethernet/marvell/mvpp2.c:2477:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UN'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UN,
^
drivers/net/ethernet/marvell/mvpp2.c:529:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UN ~(BIT(12) | BIT(13) | BIT(14))
^
drivers/net/ethernet/marvell/mvpp2.c:2488:42: note: in expansion of macro 'MVPP2_PRS_RI_L3_UN'
mvpp2_prs_shadow_ri_set(priv, pe.index, MVPP2_PRS_RI_L3_UN,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_vlan_init':
drivers/net/ethernet/marvell/mvpp2.c:517:34: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_VLAN_NONE ~(BIT(2) | BIT(3))
^
drivers/net/ethernet/marvell/mvpp2.c:2563:32: note: in expansion of macro 'MVPP2_PRS_RI_VLAN_NONE'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_VLAN_NONE,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_pppoe_init':
drivers/net/ethernet/marvell/mvpp2.c:529:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UN ~(BIT(12) | BIT(13) | BIT(14))
^
drivers/net/ethernet/marvell/mvpp2.c:2669:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UN'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UN,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_ip4_init':
drivers/net/ethernet/marvell/mvpp2.c:537:33: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UCAST ~(BIT(15) | BIT(16))
^
drivers/net/ethernet/marvell/mvpp2.c:2755:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UCAST'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UCAST,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_ip6_init':
drivers/net/ethernet/marvell/mvpp2.c:529:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UN ~(BIT(12) | BIT(13) | BIT(14))
^
drivers/net/ethernet/marvell/mvpp2.c:2823:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UN'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UN |
^
drivers/net/ethernet/marvell/mvpp2.c:537:33: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UCAST ~(BIT(15) | BIT(16))
^
drivers/net/ethernet/marvell/mvpp2.c:2887:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UCAST'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UCAST,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_mac_da_accept':
drivers/net/ethernet/marvell/mvpp2.c:524:33: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L2_UCAST ~(BIT(9) | BIT(10))
^
drivers/net/ethernet/marvell/mvpp2.c:3100:8: note: in expansion of macro 'MVPP2_PRS_RI_L2_UCAST'
ri = MVPP2_PRS_RI_L2_UCAST | MVPP2_PRS_RI_MAC_ME_MASK;
^
In file included from drivers/net/ethernet/marvell/mvpp2.c:13:0:
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_bm_pool_create':
drivers/net/ethernet/marvell/mvpp2.c:3375:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVPP2_BM_POOL_PTR_ALIGN)) {
^
include/linux/kernel.h:51:30: note: in definition of macro 'IS_ALIGNED'
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
^
drivers/net/ethernet/marvell/mvpp2.c:3375:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVPP2_BM_POOL_PTR_ALIGN)) {
^
include/linux/kernel.h:51:44: note: in definition of macro 'IS_ALIGNED'
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_bm_bufs_free':
drivers/net/ethernet/marvell/mvpp2.c:3433:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
dev_kfree_skb_any((struct sk_buff *)vaddr);
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_bm_bufs_add':
drivers/net/ethernet/marvell/mvpp2.c:3647:47: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
mvpp2_pool_refill(port, bm, (u32)phys_addr, (u32)skb);
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_rx_refill':
drivers/net/ethernet/marvell/mvpp2.c:5011:46: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
mvpp2_pool_refill(port, bm, (u32)phys_addr, (u32)skb);
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_buff_hdr_rx':
drivers/net/ethernet/marvell/mvpp2.c:5066:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
skb = (struct sk_buff *)buff_virt_addr;
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_rx':
drivers/net/ethernet/marvell/mvpp2.c:5136:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
skb = (struct sk_buff *)rx_desc->buf_cookie;
^
Introduced by commit
a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST")
"a few warnings" is a matter of perception. :-(
Please fix these up.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-11-22 0:58 UTC (permalink / raw)
To: David Miller, Networking
Cc: linux-next, linux-kernel, Giuseppe CAVALLARO, LABBE Corentin
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
between commit:
ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")
from the net tree and commit:
38ddc59d65b6 ("net: stmmac: replace all pr_xxx by their netdev_xxx counterpart")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1f9ec02fa7f8,fbd1cd79233d..000000000000
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@@ -2484,7 -2493,7 +2493,7 @@@ static int stmmac_rx(struct stmmac_pri
if (netif_msg_rx_status(priv)) {
void *rx_head;
- pr_info(">>>>>> %s: descriptor ring:\n", __func__);
- netdev_dbg(priv->dev, "%s: descriptor ring:\n", __func__);
++ netdev_info(priv->dev, ">>>>>> %s: descriptor ring:\n", __func__);
if (priv->extend_desc)
rx_head = (void *)priv->dma_erx;
else
@@@ -2571,11 -2577,11 +2580,11 @@@
frame_len -= ETH_FCS_LEN;
if (netif_msg_rx_status(priv)) {
- pr_info("\tdesc: %p [entry %d] buff=0x%x\n",
- p, entry, des);
- netdev_dbg(priv->dev, "\tdesc: %p [entry %d] buff=0x%x\n",
- p, entry, des);
++ netdev_info(priv->dev, "\tdesc: %p [entry %d] buff=0x%x\n",
++ p, entry, des);
if (frame_len > ETH_FRAME_LEN)
- pr_debug("\tframe size %d, COE: %d\n",
- frame_len, status);
+ netdev_dbg(priv->dev, "frame size %d, COE: %d\n",
+ frame_len, status);
}
/* The zero-copy is always used for all the sizes
@@@ -2628,8 -2635,11 +2638,9 @@@
DMA_FROM_DEVICE);
}
- stmmac_get_rx_hwtstamp(priv, entry, skb);
-
if (netif_msg_pktdata(priv)) {
- pr_debug("frame received (%dbytes)", frame_len);
+ netdev_dbg(priv->dev, "frame received (%dbytes)",
+ frame_len);
print_pkt(skb->data, frame_len);
}
^ permalink raw reply
* linux-next: build warning after merge of the overlayfs tree
From: Stephen Rothwell @ 2016-11-22 0:19 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: linux-next, linux-kernel
Hi Miklos,
After merging the overlayfs tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
In file included from fs/overlayfs/dir.c:20:0:
fs/overlayfs/dir.c: In function 'ovl_set_redirect':
fs/overlayfs/overlayfs.h:92:6: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
int err = vfs_setxattr(dentry, name, value, size, flags);
^
fs/overlayfs/dir.c:788:14: note: 'ret' was declared here
char *buf, *ret;
^
Introduced by commit
496654b0792e ("ovl: redirect on rename-dir")
This is not necessarily a false positive (although is is a confusing
message): if the kmalloc of "buf" fails and samedir was not set in
ovl_get_redirect(), then "return ret" will be executed but "ret" has
not been set.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the rockchip tree with the arm-soc tree
From: Olof Johansson @ 2016-11-21 23:38 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Heiko Stuebner, Arnd Bergmann, ARM, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Neil Armstrong, Kevin Hilman,
Andy Yan
In-Reply-To: <20161122101908.2e967e42@canb.auug.org.au>
Hi,
On Mon, Nov 21, 2016 at 3:19 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Heiko,
>
> Today's linux-next merge of the rockchip tree got a conflict in:
>
> arch/arm64/configs/defconfig
>
> between commit:
>
> a59294b2f7c7 ("ARM64: defconfig: Enable MMC related configs")
>
> from the arm-soc tree and commit:
>
> 5295a3157348 ("arm64: defconfig: enable RK808 components")
>
> from the rockchip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
This sounds fine, and it's a conflict we'll resolve when we merge this
material from Heiko.
-Olof
^ permalink raw reply
* linux-next: manual merge of the arm64 tree with Linus' tree
From: Stephen Rothwell @ 2016-11-21 23:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-next, linux-kernel, Will Deacon, Suzuki K Poulose
Hi Catalin,
Today's linux-next merge of the arm64 tree got a conflict in:
arch/arm64/include/asm/cpufeature.h
between commit:
272d01bd790f ("arm64: Fix circular include of asm/lse.h through linux/jump_label.h")
from Linus' tree and commits:
a4023f682739 ("arm64: Add hypervisor safe helper for checking constant capabilities")
82e0191a1aa1 ("arm64: Support systems without FP/ASIMD")
from the arm64 tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
I also added this merge fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 Nov 2016 10:30:40 +1100
Subject: [PATCH] arm64: merge fix for code movement to cpucaps.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm64/include/asm/cpucaps.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 87b446535185..4174f09678c4 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -34,7 +34,8 @@
#define ARM64_HAS_32BIT_EL0 13
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
+#define ARM64_HAS_NO_FPSIMD 16
-#define ARM64_NCAPS 16
+#define ARM64_NCAPS 17
#endif /* __ASM_CPUCAPS_H */
--
2.10.2
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/include/asm/cpufeature.h
index 0bc0b1de90c4,0ef718b67c54..000000000000
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@@ -9,9 -9,6 +9,7 @@@
#ifndef __ASM_CPUFEATURE_H
#define __ASM_CPUFEATURE_H
- #include <linux/jump_label.h>
-
+#include <asm/cpucaps.h>
#include <asm/hwcap.h>
#include <asm/sysreg.h>
@@@ -25,8 -22,34 +23,10 @@@
#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap))
#define cpu_feature(x) ilog2(HWCAP_ ## x)
-#define ARM64_WORKAROUND_CLEAN_CACHE 0
-#define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE 1
-#define ARM64_WORKAROUND_845719 2
-#define ARM64_HAS_SYSREG_GIC_CPUIF 3
-#define ARM64_HAS_PAN 4
-#define ARM64_HAS_LSE_ATOMICS 5
-#define ARM64_WORKAROUND_CAVIUM_23154 6
-#define ARM64_WORKAROUND_834220 7
-#define ARM64_HAS_NO_HW_PREFETCH 8
-#define ARM64_HAS_UAO 9
-#define ARM64_ALT_PAN_NOT_UAO 10
-#define ARM64_HAS_VIRT_HOST_EXTN 11
-#define ARM64_WORKAROUND_CAVIUM_27456 12
-#define ARM64_HAS_32BIT_EL0 13
-#define ARM64_HYP_OFFSET_LOW 14
-#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
-/*
- * The macro below will be moved to asm/cpucaps.h together with the
- * ARM64_NCAPS update.
- */
-#define ARM64_HAS_NO_FPSIMD 16
-
-#define ARM64_NCAPS 17
-
#ifndef __ASSEMBLY__
+ #include <linux/bug.h>
+ #include <linux/jump_label.h>
#include <linux/kernel.h>
/* CPU feature register tracking */
^ permalink raw reply related
* linux-next: manual merge of the rockchip tree with the arm-soc tree
From: Stephen Rothwell @ 2016-11-21 23:19 UTC (permalink / raw)
To: Heiko Stuebner, Olof Johansson, Arnd Bergmann, ARM
Cc: linux-next, linux-kernel, Neil Armstrong, Kevin Hilman, Andy Yan
Hi Heiko,
Today's linux-next merge of the rockchip tree got a conflict in:
arch/arm64/configs/defconfig
between commit:
a59294b2f7c7 ("ARM64: defconfig: Enable MMC related configs")
from the arm-soc tree and commit:
5295a3157348 ("arm64: defconfig: enable RK808 components")
from the rockchip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/configs/defconfig
index 2640e193a8c4,731cc6ade789..000000000000
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@@ -297,23 -293,10 +299,24 @@@ CONFIG_REGULATOR_MAX77620=
CONFIG_REGULATOR_PWM=y
CONFIG_REGULATOR_QCOM_SMD_RPM=y
CONFIG_REGULATOR_QCOM_SPMI=y
+ CONFIG_REGULATOR_RK808=y
CONFIG_REGULATOR_S2MPS11=y
+CONFIG_MEDIA_SUPPORT=m
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
+CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
+CONFIG_MEDIA_CONTROLLER=y
+CONFIG_VIDEO_V4L2_SUBDEV_API=y
+# CONFIG_DVB_NET is not set
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_RENESAS_FCP=m
+CONFIG_VIDEO_RENESAS_VSP1=m
CONFIG_DRM=m
CONFIG_DRM_NOUVEAU=m
+CONFIG_DRM_RCAR_DU=m
+CONFIG_DRM_RCAR_HDMI=y
+CONFIG_DRM_RCAR_LVDS=y
+CONFIG_DRM_RCAR_VSP=y
CONFIG_DRM_TEGRA=m
CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_DRM_I2C_ADV7511=m
@@@ -408,7 -393,7 +414,8 @@@ CONFIG_XEN_GRANT_DEV_ALLOC=
CONFIG_COMMON_CLK_SCPI=y
CONFIG_COMMON_CLK_CS2000_CP=y
CONFIG_COMMON_CLK_S2MPS11=y
+CONFIG_COMMON_CLK_PWM=y
+ CONFIG_COMMON_CLK_RK808=y
CONFIG_CLK_QORIQ=y
CONFIG_COMMON_CLK_QCOM=y
CONFIG_MSM_GCC_8916=y
@@@ -423,13 -406,13 +430,15 @@@ CONFIG_ARM_SMMU=
CONFIG_QCOM_SMEM=y
CONFIG_QCOM_SMD=y
CONFIG_QCOM_SMD_RPM=y
+ CONFIG_ROCKCHIP_PM_DOMAINS=y
CONFIG_ARCH_TEGRA_132_SOC=y
CONFIG_ARCH_TEGRA_210_SOC=y
+CONFIG_ARCH_TEGRA_186_SOC=y
CONFIG_EXTCON_USB_GPIO=y
CONFIG_PWM=y
+ CONFIG_PWM_ROCKCHIP=y
CONFIG_PWM_TEGRA=m
+CONFIG_PWM_MESON=m
CONFIG_COMMON_RESET_HI6220=y
CONFIG_PHY_RCAR_GEN3_USB2=y
CONFIG_PHY_HI6220_USB=y
^ permalink raw reply
* Re: linux-next: unable to fetch the watchdog tree
From: Stephen Rothwell @ 2016-11-21 22:49 UTC (permalink / raw)
To: Wim Van Sebroeck; +Cc: linux-next, linux-kernel
In-Reply-To: <20161114152615.GA16294@spo001.leaseweb.nl>
Hi Wim,
On Mon, 14 Nov 2016 16:26:16 +0100 Wim Van Sebroeck <wim@iguana.be> wrote:
>
> This has been fixed. Thanks for notifying me about it.
>
> Kind regards,
> Wim.
>
> > Hi Wim,
> >
> > For the past few days (nearly a week, sorry) fetching the watchdog tree
> > (git://www.linux-watchdog.org/linux-watchdog-next.git#master) has
> > resulted in a hung connection.
It's happening again :-(
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the jc_docs tree
From: Jonathan Corbet @ 2016-11-19 0:39 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Takashi Iwai, Stephen Rothwell, linux-next, linux-kernel,
SeongJae Park
In-Reply-To: <20161119002218.6k5snf7srxhds4ah@intel.com>
On Fri, 18 Nov 2016 16:22:18 -0800
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> Given that there is now a directory for TPM rst documentation do you
> still want all changes to your tree or is it sufficient to just cc
> linux-doc?
For stuff in security/tpm? It makes my life easier if documentation
patches come through my tree, but it's never going to be the case that
they all take that path. I'm becoming increasingly insistent that changes
to the top-level makefiles and index.rst files need to come this way;
that way, Stephen doesn't need to send me so many polite merge-conflict
emails :)
For the rest, a CC is appreciated so that I know what's going on, but if
it works better for subsystem-specific documentation patches to go
through the relevant subsystem trees, then that's how it should be done.
Thanks,
jon
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the jc_docs tree
From: Jarkko Sakkinen @ 2016-11-19 0:22 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Takashi Iwai, Stephen Rothwell, linux-next, linux-kernel,
SeongJae Park
In-Reply-To: <20161118163312.46505e6f@lwn.net>
On Fri, Nov 18, 2016 at 04:33:12PM -0700, Jonathan Corbet wrote:
> On Mon, 14 Nov 2016 09:01:13 +0100
> Takashi Iwai <tiwai@suse.de> wrote:
>
> > > In this case, I would have liked the chance to comment. This
> > > documentation belongs in the driver-api document, not the top-level one.
> > > So, in an ideal world, I'd like to see this stuff moved there, preferably
> > > with the patches going though the docs tree.
> >
> > If there needs any other changes, feel free to merge my
> > topic/restize-docs branch into yours and keep working there:
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git topic/resize-docs
>
> OK, I've done that, so this series will show up in docs-next; hopefully
> the merge conflicts will be resolved in the process.
>
> I had said that I really wanted to move it all under driver-api and put
> it into that manual, but, looking at what's there, it's not that simple.
> The driver API parts of that manual belong there, but some of the
> information is user-oriented. A long-term goal is to separate out those
> two types of information so that interested readers can more easily find
> the information relevant to them. But that won't happen for 4.10..:) So
> I'll leave things as they are for now.
>
> (Note also that the driver API manual already has a section on sound
> devices:
>
> http://static.lwn.net/kerneldoc/driver-api/sound.html
>
> This came from the driver DocBook conversion a while back. At some point
> we should really pull all that stuff together into a single document).
>
> Thanks again for doing this conversion,
>
> jon
Given that there is now a directory for TPM rst documentation do you
still want all changes to your tree or is it sufficient to just cc
linux-doc?
Thanks for fixing the issues!
/Jarkko
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the jc_docs tree
From: Jonathan Corbet @ 2016-11-18 23:33 UTC (permalink / raw)
To: Takashi Iwai
Cc: Stephen Rothwell, linux-next, linux-kernel, Jarkko Sakkinen,
SeongJae Park
In-Reply-To: <s5ha8d2ebhy.wl-tiwai@suse.de>
On Mon, 14 Nov 2016 09:01:13 +0100
Takashi Iwai <tiwai@suse.de> wrote:
> > In this case, I would have liked the chance to comment. This
> > documentation belongs in the driver-api document, not the top-level one.
> > So, in an ideal world, I'd like to see this stuff moved there, preferably
> > with the patches going though the docs tree.
>
> If there needs any other changes, feel free to merge my
> topic/restize-docs branch into yours and keep working there:
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git topic/resize-docs
OK, I've done that, so this series will show up in docs-next; hopefully
the merge conflicts will be resolved in the process.
I had said that I really wanted to move it all under driver-api and put
it into that manual, but, looking at what's there, it's not that simple.
The driver API parts of that manual belong there, but some of the
information is user-oriented. A long-term goal is to separate out those
two types of information so that interested readers can more easily find
the information relevant to them. But that won't happen for 4.10..:) So
I'll leave things as they are for now.
(Note also that the driver API manual already has a section on sound
devices:
http://static.lwn.net/kerneldoc/driver-api/sound.html
This came from the driver DocBook conversion a while back. At some point
we should really pull all that stuff together into a single document).
Thanks again for doing this conversion,
jon
^ permalink raw reply
* Re: linux-next: Tree for Nov 17
From: Paul Gortmaker @ 2016-11-18 22:12 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next@vger.kernel.org, LKML
In-Reply-To: <20161117170851.70c20904@canb.auug.org.au>
On Thu, Nov 17, 2016 at 1:08 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> There will be no linux-next releases on Friday (tomorrow) or Monday.
>
> Changes since 20161116:
FYI, I saw this warning appear today (make allmodconfig; multi arch)
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:3: symbol REMOTEPROC is selected by QCOM_ADSP_PIL
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:81: symbol QCOM_ADSP_PIL depends on REMOTEPROC
A zombie bot "git bisect run" blames this commit/merge:
Paul.
--
commit de9e059739efe4c762cde105fd312c0f66794678
Merge: d31d45e068e6 1314ed74840c
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu Nov 17 15:57:18 2016 +1100
Merge remote-tracking branch 'rpmsg/for-next'
diff --cc drivers/remoteproc/Kconfig
index 14d5d2d43a38,c199b360067f..9c41128750ca
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@@ -100,10 -106,9 +107,9 @@@ config QCOM_WCNSS_PI
tristate "Qualcomm WCNSS Peripheral Image Loader"
depends on OF && ARCH_QCOM
depends on QCOM_SMEM
+ depends on REMOTEPROC
select QCOM_MDT_LOADER
select QCOM_SCM
- select QCOM_WCNSS_IRIS
- select REMOTEPROC
help
Say y here to support the Peripheral Image Loader for the Qualcomm
Wireless Connectivity Subsystem.
>
> The net-next tree gained conflicts against the net tree.
>
> The drm tree gained a conflict against the arm tree.
>
> The block tree gained conflicts against the btrfs-kdave tree.
>
> The tip tree gained conflicts against the drm and net-next trees and a
> build failure for which I applied a merge fix patch.
>
> The kvm tree gained a conflict against the tip tree.
>
> Non-merge commits (relative to Linus' tree): 6305
> 6661 files changed, 401169 insertions(+), 146155 deletions(-)
>
> ----------------------------------------------------------------------------
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one. You should use "git fetch" and checkout or reset to the new
> master.
>
> You can see which trees have been included by looking in the Next/Trees
> file in the source. There are also quilt-import.log and merge.log
> files in the Next directory. Between each merge, the tree was built
> with a ppc64_defconfig for powerpc and an allmodconfig (with
> CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
> native build of tools/perf. After the final fixups (if any), I do an
> x86_64 modules_install followed by builds for x86_64 allnoconfig,
> powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
> (this fails its final link) and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig.
>
> Below is a summary of the state of the merge.
>
> I am currently merging 244 trees (counting Linus' and 34 trees of bug
> fix patches pending for the current merge release).
>
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
>
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
>
> Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
> Gortmaker for triage and bug fixes.
>
> --
> Cheers,
> Stephen Rothwell
>
^ permalink raw reply
* Re: linux-next: manual merge of the block tree with the btrfs-kdave tree
From: David Sterba @ 2016-11-18 17:47 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jens Axboe, Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <20161117132301.GA26525@lst.de>
On Thu, Nov 17, 2016 at 02:23:01PM +0100, Christoph Hellwig wrote:
> On Wed, Nov 16, 2016 at 07:49:29PM -0700, Jens Axboe wrote:
> > doesn't look correct, if bio_readpage_error() is called from the
> > ->bi_end_io() handler. bi_size is generally zeroed at that time.
>
> At least some of these bios are magic btrfs-internal ones that never
> reach the block layer. But I don't think all are, and both the new
> code and one of the old cases are broken. David, can you drop
> this one patch for now, and I'll restart the discussion on the
> failfast behavior on the btrfs list?
Ok, updated in today's for-next snapshot.
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree with the tip tree
From: Stephen Rothwell @ 2016-11-17 21:31 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Marcelo Tosatti, Gleb Natapov, KVM, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Fenghua Yu, He Chen
In-Reply-To: <alpine.DEB.2.20.1611170805510.3697@nanos>
Hi Thomas,
On Thu, 17 Nov 2016 08:07:27 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Thu, 17 Nov 2016, Stephen Rothwell wrote:
> > + /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
> > + static const struct cpuid_bit cpuid_bits[] = {
> > + { X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x00000006, 0 },
> > + { X86_FEATURE_EPB, CPUID_ECX, 3, 0x00000006, 0 },
> > ++ { X86_FEATURE_CAT_L3, CPUID_EBX, 1, 0x00000010, 0 },
> > ++ { X86_FEATURE_CAT_L2, CPUID_EBX, 2, 0x00000010, 0 },
> > ++ { X86_FEATURE_CDP_L3, CPUID_ECX, 2, 0x00000010, 1 },
> > + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x00000007, 0 },
> > + { X86_FEATURE_AVX512_4VNNIW, CPUID_EDX, 2, 0x00000007, 0 },
> > + { X86_FEATURE_AVX512_4FMAPS, CPUID_EDX, 3, 0x00000007, 0 },
> > + { X86_FEATURE_HW_PSTATE, CPUID_EDX, 7, 0x80000007, 0 },
> > + { X86_FEATURE_CPB, CPUID_EDX, 9, 0x80000007, 0 },
> > + { X86_FEATURE_PROC_FEEDBACK, CPUID_EDX, 11, 0x80000007, 0 },
> > + { 0, 0, 0, 0, 0 }
> > };
>
> This should be
>
> > + static const struct cpuid_bit cpuid_bits[] = {
> > + { X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x00000006, 0 },
> > + { X86_FEATURE_EPB, CPUID_ECX, 3, 0x00000006, 0 },
> > + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x00000007, 0 },
> > + { X86_FEATURE_AVX512_4VNNIW, CPUID_EDX, 2, 0x00000007, 0 },
> > + { X86_FEATURE_AVX512_4FMAPS, CPUID_EDX, 3, 0x00000007, 0 },
> > ++ { X86_FEATURE_CAT_L3, CPUID_EBX, 1, 0x00000010, 0 },
> > ++ { X86_FEATURE_CAT_L2, CPUID_EBX, 2, 0x00000010, 0 },
> > ++ { X86_FEATURE_CDP_L3, CPUID_ECX, 2, 0x00000010, 1 },
> > + { X86_FEATURE_HW_PSTATE, CPUID_EDX, 7, 0x80000007, 0 },
> > + { X86_FEATURE_CPB, CPUID_EDX, 9, 0x80000007, 0 },
> > + { X86_FEATURE_PROC_FEEDBACK, CPUID_EDX, 11, 0x80000007, 0 },
> > + { 0, 0, 0, 0, 0 }
> > };
Thanks for letting me know.
> tip will carry a proper resolution today.
Too easy.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the block tree with the btrfs-kdave tree
From: Christoph Hellwig @ 2016-11-17 13:23 UTC (permalink / raw)
To: Jens Axboe
Cc: Stephen Rothwell, David Sterba, linux-next, linux-kernel,
Christoph Hellwig
In-Reply-To: <5d5a631b-e18e-aa2b-67bb-e2df6d8bef15@kernel.dk>
On Wed, Nov 16, 2016 at 07:49:29PM -0700, Jens Axboe wrote:
> doesn't look correct, if bio_readpage_error() is called from the
> ->bi_end_io() handler. bi_size is generally zeroed at that time.
At least some of these bios are magic btrfs-internal ones that never
reach the block layer. But I don't think all are, and both the new
code and one of the old cases are broken. David, can you drop
this one patch for now, and I'll restart the discussion on the
failfast behavior on the btrfs list?
^ permalink raw reply
* next-20161117 build: 0 failures 3 warnings (next-20161117)
From: Build bot for Mark Brown @ 2016-11-17 9:20 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20161117
Git describe: next-20161117
Commit: e3b16de6a5 Add linux-next specific files for 20161117
Build Time: 84 min 54 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 1
Warnings: 3
Section Mismatches: 4
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
10 warnings 2 mismatches : arm64-allmodconfig
2 warnings 0 mismatches : arm-multi_v7_defconfig
10 warnings 2 mismatches : arm-allmodconfig
2 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 1
20 drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
Warnings Summary: 3
16 ../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
4 ../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1194:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
4 ../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
Section Mismatch Summary: 4
1 WARNING: vmlinux.o(.text+0x797db4): Section mismatch in reference from the function fsl_guts_probe() to the function .init.text:of_flat_dt_get_machine_name()
1 WARNING: vmlinux.o(.text+0x54b098): Section mismatch in reference from the function fsl_guts_probe() to the function .init.text:of_flat_dt_get_machine_name()
1 WARNING: drivers/built-in.o(.text+0x1a376c): Section mismatch in reference from the function fsl_guts_probe() to the function .init.text:of_flat_dt_get_machine_name()
1 WARNING: drivers/built-in.o(.text+0x10f9c8): Section mismatch in reference from the function fsl_guts_probe() to the function .init.text:of_flat_dt_get_machine_name()
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allnoconfig : PASS, 2 errors, 0 warnings, 0 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 2 errors, 10 warnings, 2 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
Warnings:
../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1194:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
Section Mismatches:
WARNING: drivers/built-in.o(.text+0x1a376c): Section mismatch in reference from the function fsl_guts_probe() to the function .init.text:of_flat_dt_get_machine_name()
WARNING: vmlinux.o(.text+0x797db4): Section mismatch in reference from the function fsl_guts_probe() to the function .init.text:of_flat_dt_get_machine_name()
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 2 errors, 0 warnings, 0 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 2 errors, 2 warnings, 0 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
Warnings:
../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1194:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 2 errors, 0 warnings, 0 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 2 errors, 10 warnings, 2 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
Warnings:
../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1194:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: warning: "mutex_lock_interruptible" redefined
Section Mismatches:
WARNING: drivers/built-in.o(.text+0x10f9c8): Section mismatch in reference from the function fsl_guts_probe() to the function .init.text:of_flat_dt_get_machine_name()
WARNING: vmlinux.o(.text+0x54b098): Section mismatch in reference from the function fsl_guts_probe() to the function .init.text:of_flat_dt_get_machine_name()
-------------------------------------------------------------------------------
arm-allnoconfig : PASS, 2 errors, 0 warnings, 0 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
-------------------------------------------------------------------------------
x86_64-allnoconfig : PASS, 2 errors, 0 warnings, 0 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
-------------------------------------------------------------------------------
arm-multi_v4t_defconfig : PASS, 2 errors, 0 warnings, 0 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 2 errors, 2 warnings, 0 section mismatches
Errors:
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
drivers/remoteproc/Kconfig:3:error: recursive dependency detected!
Warnings:
../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/pinctrl/sunxi/pinctrl-sunxi.c:1194:8: warning: 'best_div' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox