* [PATCH] kconfig: Sync zconf.y with zconf.tab.c_shipped
From: Ulf Magnusson @ 2017-10-05 3:06 UTC (permalink / raw)
To: yann.morin.1998, linux-kbuild
Cc: mmarek, yamada.masahiro, lacombar, linux-kernel, Ulf Magnusson
Looks like a change to a comment in zconf.y was never committed, because
the updated version only appears it zconf.tab.c_shipped. Update the
comment in zconf.y to match.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
---
scripts/kconfig/zconf.y | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index c8f396c..4b2cf41 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -101,7 +101,7 @@ static struct menu *current_menu, *current_entry;
} if_entry menu_entry choice_entry
%{
-/* Include zconf_id.c here so it can see the token constants. */
+/* Include kconf_id.c here so it can see the token constants. */
#include "kconf_id.c"
%}
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v2 0/8] Sync and consolidate Linux-derived printk, BUILD_BUG, BUG, WARN, etc.
From: Tom Rini @ 2017-10-05 3:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAK7LNATiepY1my5n1Dxw1u1AJe3h=rx=A7t4WGCV1VwuDWW8pA@mail.gmail.com>
On Wed, Oct 04, 2017 at 02:15:19PM +0900, Masahiro Yamada wrote:
> 2017-09-16 14:10 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> >
> > I tested this series with buildman.
> >
> >
> >
> > Masahiro Yamada (8):
> > stdio.h: move printf() stuff from <common.h> to <stdio.h>
> > printk: collect printk stuff into <linux/printk.h> with loglevel
> > support
> > treewide: replace with error() with pr_err()
> > common.h: remove error()
> > vsprintf.h: include <linux/types.h>
> > bug.h: sync BUILD_BUG stuff with Linux 4.13
> > bug.h: move runtime BUG/WARN macros into <linux/bug.h>
> > dm: define dev_*() log functions in DM header
>
> I am still worried if this series is dismissed.
>
> I am being blocked from importing NAND code from Linux
> due to missing/incompatible Linux-derived macros.
I am looking at this, but a default LOGLEVEL of 5 is just too high and
I'm seeing what's reasonable now.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171004/bea199de/attachment.sig>
^ permalink raw reply
* Deleting a branch after merging it results in "there may be uncommitted changes"
From: Joshua Lamusga @ 2017-10-05 3:04 UTC (permalink / raw)
To: git
Hello, I'm trying to understand Git and the mess I've made. Some time
ago, I did crazy things like adding to master even though I was
working in develop, leaving it a commit ahead and X commits behind. I
did crazier things, like trying to amend a previous post's message.
Anyway, I follow a very simple merging model for this one-person
project. Recently, I made a new local branch off of develop called
feature-printing. After checking out feature-printing, making my
changes, and committing changes, I merged it with develop. I then
immediately tried to delete feature-printing, which resulted in a
prompt asking if I was sure since it might contain uncommitted
changes. Though I've seen this problem many times on the internet, I
haven't seen it in the context of literally just merging. There are 0
steps between merging and deleting the old branch.
All of this is done in Visual Studio's GUI for Git. Any ideas?
^ permalink raw reply
* [linux-linus test] 114012: regressions - FAIL
From: osstest service owner @ 2017-10-05 3:01 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 13110 bytes --]
flight 114012 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-install fail REGR. vs. 113982
build-armhf-libvirt 6 libvirt-build fail REGR. vs. 113982
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 113982
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 113982
test-amd64-amd64-xl-rtds 10 debian-install fail like 113982
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 113982
test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qcow2 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
version targeted for testing:
linux b7e14164417865e24b6a1b09110b63c01158fc8e
baseline version:
linux d81fa669e3de7eb8a631d7d95dac5fbcb2bf9d4e
Last test of basis 113982 2017-10-04 01:01:34 Z 1 days
Testing same since 114012 2017-10-04 17:20:45 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Alexandre Bounine <alexandre.bounine@idt.com>
Alexandru Moise <00moses.alexander00@gmail.com>
Andrea Arcangeli <aarcange@redhat.com>
Andrei Vagin <avagin@virtuozzo.com>
Andrew Morton <akpm@linux-foundation.org>
Arnd Bergmann <arnd@arndb.de>
Artem Savkov <asavkov@redhat.com>
Arve Hjønnevåg <arve@android.com>
Casey Schaufler <casey@schaufler-ca.com>
Christophe Leroy <christophe.leroy@c-s.fr>
Colin Ian King <colin.king@canonical.com>
Cyrill Gorcunov <gorcunov@gmail.com>
Cyrill Gorcunov <gorcunov@openvz.org>
Davidlohr Bueso <dave@stgolabs.net>
Davidlohr Bueso <dbueso@suse.de>
Eric Biggers <ebiggers@google.com>
Frank Kunz <frank.kunz@nokia.com>
Geert Uytterhoeven <geert+renesas@glider.be>
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ingo Molnar <mingo@kernel.org>
Ioan Nicu <ioan.nicu.ext@nokia.com>
Jacopo Mondi <jacopo+renesas@jmondi.org>
Jakub Kicinski <jakub.kicinski@netronome.com>
James Morris <james.l.morris@oracle.com>
Jean Delvare <jdelvare@suse.de>
Jeff Layton <jlayton@redhat.com>
Joe Perches <joe@perches.com>
Johannes Thumshirn <jthumshirn@suse.de>
Johannes Weiner <hannes@cmpxchg.org>
Jérôme Glisse <jglisse@redhat.com>
Kees Cook <keescook@chromium.org>
Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Kirill Tkhai <ktkhai@virtuozzo.com>
Linus Torvalds <torvalds@linux-foundation.org>
Luis R. Rodriguez <mcgrof@kernel.org>
Mark Rutland <mark.rutland@arm.com>
Masahiro Yamada <yamada.masahiro@socionext.com>
Mel Gorman <mgorman@techsingularity.net>
Michal Hocko <mhocko@suse.com>
Mike Rapoport <rppt@linux.vnet.ibm.com>
Minchan Kim <minchan@kernel.org>
Oleg Nesterov <oleg@redhat.com>
Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reza Arbab <arbab@linux.vnet.ibm.com>
Rusty Russell <rusty@rustcorp.com.au>
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Shaohua Li <shli@fb.com>
Sherry Yang <sherryy@android.com>
Shu Wang <shuwang@redhat.com>
Stafford Horne <shorne@gmail.com>
Steven Rostedt (VMware) <rostedt@goodmis.org>
Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Vitaly Wool <vitalywool@gmail.com>
Vladimir Davydov <vdavydov.dev@gmail.com>
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
YASUAKI ISHIMATSU <yasu.isimatu@gmail.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt fail
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm blocked
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 pass
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 pass
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale fail
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-examine pass
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-xl-qemut-win10-i386 fail
test-amd64-i386-xl-qemut-win10-i386 fail
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt blocked
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-amd64-i386-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw blocked
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 1987 lines long.)
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 15/25] xfs: scrub refcount btrees
From: Dave Chinner @ 2017-10-05 2:59 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <150706334388.19351.17983785124391880595.stgit@magnolia>
On Tue, Oct 03, 2017 at 01:42:23PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> +/* Scrub a refcountbt record. */
> +STATIC int
> +xfs_scrub_refcountbt_helper(
> + struct xfs_scrub_btree *bs,
> + union xfs_btree_rec *rec)
> +{
> + struct xfs_mount *mp = bs->cur->bc_mp;
> + struct xfs_agf *agf;
> + struct xfs_refcount_irec irec;
> + unsigned long long rec_end;
> + xfs_agblock_t eoag;
> + bool has_cowflag;
> + int error = 0;
> +
> + irec.rc_startblock = be32_to_cpu(rec->refc.rc_startblock);
> + irec.rc_blockcount = be32_to_cpu(rec->refc.rc_blockcount);
> + irec.rc_refcount = be32_to_cpu(rec->refc.rc_refcount);
> + agf = XFS_BUF_TO_AGF(bs->sc->sa.agf_bp);
> + eoag = be32_to_cpu(agf->agf_length);
> +
> + /* Only CoW records can have refcount == 1. */
> + has_cowflag = !!(irec.rc_startblock & XFS_REFC_COW_START);
> + if ((irec.rc_refcount == 1 && !has_cowflag) ||
> + (irec.rc_refcount != 1 && has_cowflag))
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + /* Check the extent. */
> + irec.rc_startblock &= ~XFS_REFC_COW_START;
> + rec_end = (unsigned long long)irec.rc_startblock + irec.rc_blockcount;
> + if (irec.rc_startblock >= mp->m_sb.sb_agblocks ||
> + irec.rc_startblock >= eoag ||
> + irec.rc_blockcount == 0 ||
> + rec_end > mp->m_sb.sb_agblocks ||
> + rec_end > eoag ||
For the (broken) record...
> + irec.rc_refcount < 1)
Unsigned variable, so it seems to me that irec.rc_refcount == 0
would be a more correct check.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH 14/25] xfs: scrub rmap btrees
From: Dave Chinner @ 2017-10-05 2:56 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <150706333767.19351.13637260621369926859.stgit@magnolia>
On Tue, Oct 03, 2017 at 01:42:17PM -0700, Darrick J. Wong wrote:
> +/* Scrub an rmapbt record. */
> +STATIC int
> +xfs_scrub_rmapbt_helper(
> + struct xfs_scrub_btree *bs,
> + union xfs_btree_rec *rec)
> +{
> + struct xfs_mount *mp = bs->cur->bc_mp;
> + struct xfs_agf *agf;
> + struct xfs_rmap_irec irec;
> + unsigned long long rec_end;
> + xfs_agblock_t eoag;
> + bool non_inode;
> + bool is_unwritten;
> + bool is_bmbt;
> + bool is_attr;
> + int error;
> +
> + error = xfs_rmap_btrec_to_irec(rec, &irec);
> + if (!xfs_scrub_btree_op_ok(bs->sc, bs->cur, 0, &error))
> + goto out;
This got me again. Again I was thinking that this code threw
away the error from xfs_rmap_btrec_to_irec(). Could we consider
renaming "op_ok" to "process_error" or something like that so
it's clearer that it's doing some kind of checking on the error
we just got back?
> +
> + /* Check extent. */
> + agf = XFS_BUF_TO_AGF(bs->sc->sa.agf_bp);
> + eoag = be32_to_cpu(agf->agf_length);
> + rec_end = (unsigned long long)irec.rm_startblock + irec.rm_blockcount;
> +
> + if (irec.rm_startblock >= mp->m_sb.sb_agblocks ||
> + irec.rm_startblock >= eoag ||
> + irec.rm_blockcount == 0 ||
> + rec_end > mp->m_sb.sb_agblocks ||
> + rec_end > eoag)
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
Broken Record (tm).
> + /* Check flags. */
> + non_inode = XFS_RMAP_NON_INODE_OWNER(irec.rm_owner);
> + is_bmbt = irec.rm_flags & XFS_RMAP_BMBT_BLOCK;
> + is_attr = irec.rm_flags & XFS_RMAP_ATTR_FORK;
> + is_unwritten = irec.rm_flags & XFS_RMAP_UNWRITTEN;
> +
> + if (is_bmbt && irec.rm_offset != 0)
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + if (non_inode && irec.rm_offset != 0)
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + if (is_unwritten && (is_bmbt || non_inode || is_attr))
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + if (non_inode && (is_bmbt || is_unwritten || is_attr))
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + if (!non_inode) {
> + xfs_agnumber_t agno = XFS_INO_TO_AGNO(mp, irec.rm_owner);
> + xfs_agino_t agino = XFS_INO_TO_AGINO(mp, irec.rm_owner);
> + xfs_agblock_t agbno = XFS_AGINO_TO_AGBNO(mp, agino);
> +
> + /* Owner inode within an AG? */
> + if (agno >= mp->m_sb.sb_agcount ||
> + agbno >= mp->m_sb.sb_agblocks)
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + /* Owner inode within the FS? */
> + if (XFS_AGB_TO_DADDR(mp, agno, agbno) >=
> + XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks))
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
These two checks probably also should be libxfs functionality.
We've got similar checks strewn all over the place (e.g. valid_bno()
in xfs_db, verify_aginum/verify_inum/verify_agbno/verify_dfsbno
in repair, etc.
It would be good to get all these sorts of basic type checks
centralised and used consistenly by all the code....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH] cma: Take __GFP_NOWARN into account in cma_alloc()
From: Anshuman Khandual @ 2017-10-05 2:55 UTC (permalink / raw)
To: Boris Brezillon, linux-mm, Andrew Morton, Laura Abbott
Cc: Jaewon Kim, David Airlie, Daniel Vetter, dri-devel, Eric Anholt
In-Reply-To: <20171004125447.15195-1-boris.brezillon@free-electrons.com>
On 10/04/2017 06:24 PM, Boris Brezillon wrote:
> cma_alloc() unconditionally prints an INFO message when the CMA
> allocation fails. Make this message conditional on the non-presence of
> __GFP_NOWARN in gfp_mask.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Hello,
>
> This patch aims at removing INFO messages that are displayed when the
> VC4 driver tries to allocate buffer objects. From the driver perspective
> an allocation failure is acceptable, and the driver can possibly do
> something to make following allocation succeed (like flushing the VC4
> internal cache).
>
> Also, I don't understand why this message is only an INFO message, and
> not a WARN (pr_warn()). Please let me know if you have good reasons to
> keep it as an unconditional pr_info()
Making it conditional (__GFP_NOWARN based what you already have) with
pr_warn() message makes more sense.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 5/8] net/i40e: finish integration FDIR with generic flow API
From: Wu, Jingjing @ 2017-10-05 2:52 UTC (permalink / raw)
To: Xing, Beilei; +Cc: Chilikin, Andrey, dev@dpdk.org
In-Reply-To: <1506700252-34949-6-git-send-email-beilei.xing@intel.com>
> -----Original Message-----
> From: Xing, Beilei
> Sent: Friday, September 29, 2017 11:51 PM
> To: Wu, Jingjing <jingjing.wu@intel.com>
> Cc: Chilikin, Andrey <andrey.chilikin@intel.com>; dev@dpdk.org
> Subject: [PATCH v7 5/8] net/i40e: finish integration FDIR with generic flow API
>
> rte_eth_fdir_* structures are still used in FDIR functions.
> This patch adds i40e private FDIR related structures and
> functions to finish integration FDIR with generic flow API.
>
> Signed-off-by: Beilei Xing <beilei.xing@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
^ permalink raw reply
* Re: [PATCH v7 2/8] net/i40e: update ptype and pctype info
From: Wu, Jingjing @ 2017-10-05 2:51 UTC (permalink / raw)
To: Xing, Beilei; +Cc: Chilikin, Andrey, dev@dpdk.org
In-Reply-To: <1506700252-34949-3-git-send-email-beilei.xing@intel.com>
> -----Original Message-----
> From: Xing, Beilei
> Sent: Friday, September 29, 2017 11:51 PM
> To: Wu, Jingjing <jingjing.wu@intel.com>
> Cc: Chilikin, Andrey <andrey.chilikin@intel.com>; dev@dpdk.org
> Subject: [PATCH v7 2/8] net/i40e: update ptype and pctype info
>
> Update new packet type and new pctype info when downloading
> profile.
>
> Signed-off-by: Beilei Xing <beilei.xing@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
^ permalink raw reply
* Re: [PATCH] drivers/x86: add thinkpad-wmi
From: Darren Hart @ 2017-10-05 2:49 UTC (permalink / raw)
To: Corentin Chary
Cc: Andy Shevchenko, Andy Shevchenko, Platform Driver,
linux-kernel@vger.kernel.org
In-Reply-To: <CAHR064jrkntSf8_5kiL5x8B+_BwCHrrZajgedYe-FNt439wDpA@mail.gmail.com>
On Tue, Sep 05, 2017 at 09:07:27AM +0200, Corentin Chary wrote:
> [re-send for the mailing list, I forgot that gmail was stupid]
>
> On Tue, Sep 5, 2017 at 9:05 AM, Corentin Chary <corentin.chary@gmail.com> wrote:
> >>
> >> I didn't read the code, does it use WMI bus which Andy L. introduced
> >> recently?
> >>
> >
> > No, I wasn't aware of it. I checked the dell-wmi conversion patch and it
> > should not be too hard.
> > I'll probably sent that as a patch on top the existing driver (in the same
> > series).
Hi Corentin,
Just to make sure I haven't missed it - I believe we're waiting for a v2 of this
patch. Is that right?
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* [PATCH 1/1] iio: inkern: add helper to enable a channel
From: Phil Reid @ 2017-10-05 2:37 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, preid, linux-iio
This is done by calling a generic write attribute helper similar
to the existing read attribute helper. Update write raw helper
to use new write attribute function.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/iio/inkern.c | 17 +++++++++++++++--
include/linux/iio/consumer.h | 9 +++++++++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 069defc..51c5c967 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -850,7 +850,9 @@ static int iio_channel_write(struct iio_channel *chan, int val, int val2,
chan->channel, val, val2, info);
}
-int iio_write_channel_raw(struct iio_channel *chan, int val)
+static int iio_write_channel_attribute(struct iio_channel *chan,
+ int val, int val2,
+ enum iio_chan_info_enum attribute)
{
int ret;
@@ -860,14 +862,25 @@ int iio_write_channel_raw(struct iio_channel *chan, int val)
goto err_unlock;
}
- ret = iio_channel_write(chan, val, 0, IIO_CHAN_INFO_RAW);
+ ret = iio_channel_write(chan, val, val2, attribute);
err_unlock:
mutex_unlock(&chan->indio_dev->info_exist_lock);
return ret;
}
+
+int iio_write_channel_raw(struct iio_channel *chan, int val)
+{
+ return iio_write_channel_attribute(chan, val, 0, IIO_CHAN_INFO_RAW);
+}
EXPORT_SYMBOL_GPL(iio_write_channel_raw);
+int iio_write_channel_enable(struct iio_channel *chan, int val)
+{
+ return iio_write_channel_attribute(chan, val, 0, IIO_CHAN_INFO_ENABLE);
+}
+EXPORT_SYMBOL_GPL(iio_write_channel_enable);
+
unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
{
const struct iio_chan_spec_ext_info *ext_info;
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 5e347a9..4a5a90d 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -226,6 +226,15 @@ int iio_read_channel_raw(struct iio_channel *chan,
int iio_write_channel_raw(struct iio_channel *chan, int val);
/**
+ * iio_write_channel_enable() - enable a given channel
+ * @chan: The channel being queried.
+ * @val: Value being written.
+ *
+ * Enable / disable the channel.
+ */
+int iio_write_channel_enable(struct iio_channel *chan, int val);
+
+/**
* iio_read_max_channel_raw() - read maximum available raw value from a given
* channel, i.e. the maximum possible value.
* @chan: The channel being queried.
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 0/8] Introduce support for Dell SMBIOS over WMI
From: Darren Hart @ 2017-10-05 2:44 UTC (permalink / raw)
To: Mario.Limonciello
Cc: andy.shevchenko, linux-kernel, platform-driver-x86, luto,
quasisec, pali.rohar
In-Reply-To: <bff1f575d2d44b79ba9636433f19df9d@ausx13mpc120.AMER.DELL.COM>
On Sat, Sep 30, 2017 at 07:56:33PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@infradead.org]
> > Sent: Friday, September 29, 2017 9:17 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: Andy Shevchenko <andy.shevchenko@gmail.com>; LKML <linux-
> > kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; Andy Lutomirski
> > <luto@kernel.org>; quasisec@google.com; pali.rohar@gmail.com
> > Subject: Re: [PATCH v3 0/8] Introduce support for Dell SMBIOS over WMI
> >
> > On Wed, Sep 27, 2017 at 11:02:12PM -0500, Mario Limonciello wrote:
...
> > My other concern is the freeform structure around creating the file
> > operations in each driver for the chardev IOCTL. It seems like we need
> > some kind of defined mapping from METHOD index to IOCTL number, or else
> > some way to advertise what it is?
> >
>
> I was originally thinking it would be a good way to do this cleanly too, but my
> main concern is this one character device may handle multiple methods problem.
> If you map method instance (index) to ioctl number you will most likely run into
> clashes. So maybe it's worth not allowing that?
>
> So I've got another idea. How about instead of a variety of freeform ioctl per driver,
> provide three ioctl functions for all the character devices that come in through
> the WMI bus to use (say IOC 'W') with either read, write or write/read. The WMI bus
> should be able to know which driver to pass it on to by the character device used.
>
This is not something I have any experience with. I see you added it to v4, so
let's see what others have to say there.
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* Re: [PATCH v2] rpmsg: Allow RPMSG_VIRTIO to be enabled via menuconfig or defconfig
From: Bjorn Andersson @ 2017-10-05 2:44 UTC (permalink / raw)
To: Anup Patel; +Cc: Ohad Ben-Cohen, linux-remoteproc, linux-kernel
In-Reply-To: <1506917900-12289-1-git-send-email-anup@brainfault.org>
On Sun 01 Oct 21:18 PDT 2017, Anup Patel wrote:
> Currently, RPMSG_VIRTIO can only be enabled if some other kconfig
> option selects it. This does not allow it to be enabled for
> virtualized systems where Virtio RPMSG is available over Virtio
> MMIO or PCI transport.
>
> This patch updates RPMSG_VIRTIO kconfig option so that we can
> enable the VirtIO RPMSG driver via menuconfig or defconfig.
>
> Signed-off-by: Anup Patel <anup@brainfault.org>
> ---
This part looks good (and really I think this is the right thing to do).
But turning RPMSG_VIRTIO into a user selectable item makes it invalid to
"select RPMSG_VIRTIO" from drivers/remoteproc/Kconfig.
Can you please as part of this change remove those selects and as a
separate patch add CONFIG_RPMSG_VIRTIO=m to
arch/arm/configs/multi_v7_defconfig?
Thanks,
Bjorn
>
> Changes since v1:
> - Add depends on HAS_DMA to avoid build failures on
> archs (such as um) with NO_DMA=y. For most archs,
> HAS_DMA=y so having depends on HAS_DMA is fine.
>
> drivers/rpmsg/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index 0fe6eac..65a9f6b 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -47,7 +47,8 @@ config RPMSG_QCOM_SMD
> platforms.
>
> config RPMSG_VIRTIO
> - tristate
> + tristate "Virtio RPMSG bus driver"
> + depends on HAS_DMA
> select RPMSG
> select VIRTIO
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: Build regressions/improvements in v4.14-rc3
From: Michael Ellerman @ 2017-10-05 2:43 UTC (permalink / raw)
To: Thomas Meyer; +Cc: Geert Uytterhoeven, linux-kernel@vger.kernel.org
In-Reply-To: <20171003092727.dqcfgil7wty4mdus@olymp>
Thomas Meyer <thomas@m3y3r.de> writes:
> On Tue, Oct 03, 2017 at 08:18:14PM +1100, Michael Ellerman wrote:
...
>>
>> I've switched it to using one of the toolchains from Free Electrons,
>> which is built with glibc, and that seems to be working:
>>
>> http://kisskb.ellerman.id.au/kisskb/buildresult/13171418/
>>
>>
>> Let me know if that's no good.
>
> Cool, excellent! Look good.
>
> Is it also possible to add an allyesconfig and allmodconfig for UML?
Sure.
http://kisskb.ellerman.id.au/kisskb/config/484/
http://kisskb.ellerman.id.au/kisskb/config/485/
They don't build :D
arch/um/drivers/vde_user.c:8:24: fatal error: libvdeplug.h: No such file or directory
Can I just disable that driver? I'd prefer not to install too many host
packages just to get UML building.
cheers
^ permalink raw reply
* Re: [PATCH] platform/x86: silead_dmi: Add entry for the Chuwi Hi8 Pro tablet
From: Darren Hart @ 2017-10-05 2:40 UTC (permalink / raw)
To: Hans de Goede
Cc: Andy Shevchenko, Dave Olsthoorn, platform-driver-x86,
linux-kernel
In-Reply-To: <20171004133012.10625-1-hdegoede@redhat.com>
On Wed, Oct 04, 2017 at 03:30:12PM +0200, Hans de Goede wrote:
> Add touchscreen platform data for the Chuwi Hi8 Pro tablet.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Queued for testing, thanks Hans.
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* [PATCH] kconfig: Remove menu_end_entry()
From: Ulf Magnusson @ 2017-10-05 2:36 UTC (permalink / raw)
To: yann.morin.1998, linux-kbuild
Cc: mmarek, yamada.m, lacombar, linux-kernel, Ulf Magnusson
menu_end_entry() is empty and completely unused as far as I can tell:
$ git log -G menu_end_entry --oneline
a02f057 [PATCH] kconfig: improve error handling in the parser
1da177e Linux-2.6.12-rc2
Last one is the initial Git commit, where menu_end_entry() is empty as
well. I couldn't find anything that redefined it on Google either.
It might be a debugging helper for setting a breakpoint after each
config, menuconfig, and comment is parsed. IMO it hurts more than it
helps in that case by making the parsing code look more complicated at a
glance than it really is, and I suspect it doesn't get used much.
Tested by running the Kconfiglib test suite, which indirectly verifies
that the .config files generated by the C implementation for each
defconfig file in the kernel stays the same.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
---
scripts/kconfig/lkc.h | 1 -
| 5 -----
scripts/kconfig/zconf.tab.c_shipped | 30 ++++++++++--------------------
scripts/kconfig/zconf.y | 6 +-----
4 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index cdcbe43..16cb62b 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -100,7 +100,6 @@ void menu_warn(struct menu *menu, const char *fmt, ...);
struct menu *menu_add_menu(void);
void menu_end_menu(void);
void menu_add_entry(struct symbol *sym);
-void menu_end_entry(void);
void menu_add_dep(struct expr *dep);
void menu_add_visibility(struct expr *dep);
struct property *menu_add_prompt(enum prop_type type, char *prompt, struct expr *dep);
--git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index e935793..503f3ae 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -62,13 +62,8 @@ void menu_add_entry(struct symbol *sym)
menu_add_symbol(P_SYMBOL, sym, NULL);
}
-void menu_end_entry(void)
-{
-}
-
struct menu *menu_add_menu(void)
{
- menu_end_entry();
last_entry_ptr = ¤t_entry->list;
return current_menu = current_entry;
}
diff --git a/scripts/kconfig/zconf.tab.c_shipped b/scripts/kconfig/zconf.tab.c_shipped
index a22b285..7938548 100644
--- a/scripts/kconfig/zconf.tab.c_shipped
+++ b/scripts/kconfig/zconf.tab.c_shipped
@@ -516,16 +516,16 @@ static const yytype_uint16 yyrline[] =
0, 109, 109, 109, 111, 111, 113, 115, 116, 117,
118, 119, 120, 124, 128, 128, 128, 128, 128, 128,
128, 128, 128, 132, 133, 134, 135, 136, 137, 141,
- 142, 148, 156, 162, 170, 180, 182, 183, 184, 185,
- 186, 187, 190, 198, 204, 214, 220, 226, 232, 235,
- 237, 248, 249, 254, 263, 268, 276, 279, 281, 282,
- 283, 284, 285, 288, 294, 305, 311, 321, 323, 328,
- 336, 344, 347, 349, 350, 351, 356, 363, 370, 375,
- 383, 386, 388, 389, 390, 393, 401, 408, 415, 421,
- 428, 430, 431, 432, 435, 443, 445, 446, 449, 456,
- 458, 463, 464, 467, 468, 469, 473, 474, 477, 478,
- 481, 482, 483, 484, 485, 486, 487, 488, 489, 490,
- 491, 494, 495, 498, 499
+ 142, 148, 156, 161, 169, 178, 180, 181, 182, 183,
+ 184, 185, 188, 196, 202, 212, 218, 224, 230, 233,
+ 235, 246, 247, 252, 261, 266, 274, 277, 279, 280,
+ 281, 282, 283, 286, 292, 303, 309, 319, 321, 326,
+ 334, 342, 345, 347, 348, 349, 354, 361, 368, 373,
+ 381, 384, 386, 387, 388, 391, 399, 406, 411, 417,
+ 424, 426, 427, 428, 431, 439, 441, 442, 445, 452,
+ 454, 459, 460, 463, 464, 465, 469, 470, 473, 474,
+ 477, 478, 479, 480, 481, 482, 483, 484, 485, 486,
+ 487, 490, 491, 494, 495
};
#endif
@@ -1552,7 +1552,6 @@ yyreduce:
case 32:
{
- menu_end_entry();
printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno());
}
@@ -1576,7 +1575,6 @@ yyreduce:
current_entry->prompt->type = P_MENU;
else
zconfprint("warning: menuconfig statement without prompt");
- menu_end_entry();
printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno());
}
@@ -1821,14 +1819,6 @@ yyreduce:
break;
- case 87:
-
- {
- menu_end_entry();
-}
-
- break;
-
case 88:
{
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index c8f396c..3845aa9 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -155,7 +155,6 @@ config_entry_start: T_CONFIG T_WORD T_EOL
config_stmt: config_entry_start config_option_list
{
- menu_end_entry();
printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno());
};
@@ -173,7 +172,6 @@ menuconfig_stmt: menuconfig_entry_start config_option_list
current_entry->prompt->type = P_MENU;
else
zconfprint("warning: menuconfig statement without prompt");
- menu_end_entry();
printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno());
};
@@ -406,9 +404,7 @@ comment: T_COMMENT prompt T_EOL
};
comment_stmt: comment depends_list
-{
- menu_end_entry();
-};
+;
/* help option */
--
2.7.4
^ permalink raw reply related
* auxdisplay drivers
From: Randy Dunlap @ 2017-10-05 2:36 UTC (permalink / raw)
To: LKML, Miguel Ojeda Sandonis
Hi Miguel,
Is this entry in MAINTAINERS still accurate?
I can't reach either of the web sites listed.
AUXILIARY DISPLAY DRIVERS
M: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com>
W: http://miguelojeda.es/auxdisplay.htm
W: http://jair.lab.fi.uva.es/~migojed/auxdisplay.htm
S: Maintained
F: drivers/auxdisplay/
F: include/linux/cfag12864b.h
Thanks,
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when requested by drivers
From: Darren Hart @ 2017-10-05 2:33 UTC (permalink / raw)
To: Mario Limonciello
Cc: Andy Shevchenko, LKML, platform-driver-x86, Andy Lutomirski,
quasisec, pali.rohar, rjw, mjg59, hch, Greg KH
In-Reply-To: <528c9a1ca4fa2f29aedbb37d3ed13c480ef093fc.1507156392.git.mario.limonciello@dell.com>
On Wed, Oct 04, 2017 at 05:48:38PM -0500, Mario Limonciello wrote:
> For WMI operations that are only Set or Query read or write sysfs
> attributes created by WMI vendor drivers make sense.
>
> For other WMI operations that are run on Method, there needs to be a
> way to guarantee to userspace that the results from the method call
> belong to the data request to the method call. Sysfs attributes don't
> work well in this scenario because two userspace processes may be
> competing at reading/writing an attribute and step on each other's
> data.
>
> When a WMI vendor driver declares an ioctl in a file_operations object
> the WMI bus driver will create a character device that maps to those
> file operations.
>
> That character device will correspond to this path:
> /dev/wmi/$driver
>
> The WMI bus driver will interpret the IOCTL calls, test them for
> a valid instance and pass them on to the vendor driver to run.
>
> This creates an implicit policy that only driver per character
> device. If a module matches multiple GUID's, the wmi_devices
> will need to be all handled by the same wmi_driver if the same
> character device is used.
>
> The WMI vendor drivers will be responsible for managing access to
> this character device and proper locking on it.
>
> When a WMI vendor driver is unloaded the WMI bus driver will clean
> up the character device.
>
> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
> MAINTAINERS | 1 +
> drivers/platform/x86/wmi.c | 67 +++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/wmi.h | 2 ++
> include/uapi/linux/wmi.h | 10 +++++++
> 4 files changed, 79 insertions(+), 1 deletion(-)
> create mode 100644 include/uapi/linux/wmi.h
>
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
...
> +static long wmi_ioctl(struct file *filp, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct wmi_driver *wdriver;
> + struct wmi_block *wblock;
> + const char *driver_name;
> + struct list_head *p;
> + bool found = false;
> +
> + if (_IOC_TYPE(cmd) != WMI_IOC)
> + return -ENOTTY;
> +
> + driver_name = filp->f_path.dentry->d_iname;
> +
> + list_for_each(p, &wmi_block_list) {
> + wblock = list_entry(p, struct wmi_block, list);
> + wdriver = container_of(wblock->dev.dev.driver,
> + struct wmi_driver, driver);
> + if (strcmp(driver_name, wdriver->driver.name) == 0) {
> + found = true;
> + break;
A bit of a nitpic, but the "found" variable isn't necessary. The wdriver
pointer is sufficient:
if (strcmp(driver_name, wdriver->driver.name) == 0)
break;
wdriver = NULL;
> + if (!found ||
if (wdriver || ...
And you save a local variable and a couple lines.
...
> static int wmi_dev_probe(struct device *dev)
> {
> struct wmi_block *wblock = dev_to_wblock(dev);
> struct wmi_driver *wdriver =
> container_of(dev->driver, struct wmi_driver, driver);
> int ret = 0;
> + char *buf;
>
> if (ACPI_FAILURE(wmi_method_enable(wblock, 1)))
> dev_warn(dev, "failed to enable device -- probing anyway\n");
>
> + /* driver wants a character device made */
> + if (wdriver->file_operations) {
> + buf = kmalloc(strlen(wdriver->driver.name) + 4, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> + strcpy(buf, "wmi/");
> + strcpy(buf + 4, wdriver->driver.name);
sprintf(buf, "wmi/%s", wdriver->driver.name)
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* [PATCH] clk: sunxi-ng: a83t: Fix invalid csi-mclk mux offset
From: megous at megous.com @ 2017-10-05 2:33 UTC (permalink / raw)
To: linux-arm-kernel
From: Ondrej Jirman <megous@megous.com>
Datasheet specified that parent MUX settings are at bits [10:8],
but current implementation specifies incorrect offset at [10:12].
Fix this.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
index b0fbdaea76de..d7938ab57429 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -534,7 +534,7 @@ static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(csi_mclk_clk, "csi-mclk",
csi_mclk_parents, csi_mclk_table,
0x134,
0, 5, /* M */
- 10, 3, /* mux */
+ 8, 3, /* mux */
BIT(15), /* gate */
0);
--
2.14.2
^ permalink raw reply related
* [PATCH] clk: sunxi-ng: a83t: Fix invalid csi-mclk mux offset
From: megous @ 2017-10-05 2:33 UTC (permalink / raw)
To: dev
Cc: Ondrej Jirman, Maxime Ripard, Chen-Yu Tsai, Michael Turquette,
Stephen Boyd, moderated list:ARM/Allwinner sunXi SoC support,
open list:COMMON CLK FRAMEWORK, open list
From: Ondrej Jirman <megous@megous.com>
Datasheet specified that parent MUX settings are at bits [10:8],
but current implementation specifies incorrect offset at [10:12].
Fix this.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
index b0fbdaea76de..d7938ab57429 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -534,7 +534,7 @@ static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(csi_mclk_clk, "csi-mclk",
csi_mclk_parents, csi_mclk_table,
0x134,
0, 5, /* M */
- 10, 3, /* mux */
+ 8, 3, /* mux */
BIT(15), /* gate */
0);
--
2.14.2
^ permalink raw reply related
* [PATCH] clk: uniphier: fix DAPLL2 clock rate of Pro5
From: Masahiro Yamada @ 2017-10-05 2:32 UTC (permalink / raw)
To: linux-arm-kernel
The parent of DAPLL2 should be DAPLL1. Fix the clock connection.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/clk/uniphier/clk-uniphier-sys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c b/drivers/clk/uniphier/clk-uniphier-sys.c
index 0e396f3..bffe095 100644
--- a/drivers/clk/uniphier/clk-uniphier-sys.c
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -123,7 +123,7 @@ const struct uniphier_clk_data uniphier_sld8_sys_clk_data[] = {
const struct uniphier_clk_data uniphier_pro5_sys_clk_data[] = {
UNIPHIER_CLK_FACTOR("spll", -1, "ref", 120, 1), /* 2400 MHz */
UNIPHIER_CLK_FACTOR("dapll1", -1, "ref", 128, 1), /* 2560 MHz */
- UNIPHIER_CLK_FACTOR("dapll2", -1, "ref", 144, 125), /* 2949.12 MHz */
+ UNIPHIER_CLK_FACTOR("dapll2", -1, "dapll1", 144, 125), /* 2949.12 MHz */
UNIPHIER_CLK_FACTOR("uart", 0, "dapll2", 1, 40),
UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 48),
UNIPHIER_PRO5_SYS_CLK_NAND(2),
--
2.7.4
^ permalink raw reply related
* [PATCH] clk: uniphier: fix DAPLL2 clock rate of Pro5
From: Masahiro Yamada @ 2017-10-05 2:32 UTC (permalink / raw)
To: linux-clk
Cc: Masahiro Yamada, Michael Turquette, Stephen Boyd, linux-kernel,
linux-arm-kernel
The parent of DAPLL2 should be DAPLL1. Fix the clock connection.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/clk/uniphier/clk-uniphier-sys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c b/drivers/clk/uniphier/clk-uniphier-sys.c
index 0e396f3..bffe095 100644
--- a/drivers/clk/uniphier/clk-uniphier-sys.c
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -123,7 +123,7 @@ const struct uniphier_clk_data uniphier_sld8_sys_clk_data[] = {
const struct uniphier_clk_data uniphier_pro5_sys_clk_data[] = {
UNIPHIER_CLK_FACTOR("spll", -1, "ref", 120, 1), /* 2400 MHz */
UNIPHIER_CLK_FACTOR("dapll1", -1, "ref", 128, 1), /* 2560 MHz */
- UNIPHIER_CLK_FACTOR("dapll2", -1, "ref", 144, 125), /* 2949.12 MHz */
+ UNIPHIER_CLK_FACTOR("dapll2", -1, "dapll1", 144, 125), /* 2949.12 MHz */
UNIPHIER_CLK_FACTOR("uart", 0, "dapll2", 1, 40),
UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 48),
UNIPHIER_PRO5_SYS_CLK_NAND(2),
--
2.7.4
^ permalink raw reply related
* [PATCH] reset: uniphier: add PXs3 reset data
From: Masahiro Yamada @ 2017-10-05 2:30 UTC (permalink / raw)
To: Philipp Zabel
Cc: Masahiro Yamada, devicetree, linux-kernel, Rob Herring,
Mark Rutland, linux-arm-kernel
Add basic reset data for Socionext's new SoC PXs3.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
.../devicetree/bindings/reset/uniphier-reset.txt | 3 +++
drivers/reset/reset-uniphier.c | 26 ++++++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
index 68a6f48..93efed6 100644
--- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
+++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
@@ -13,6 +13,7 @@ Required properties:
"socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC
"socionext,uniphier-ld11-reset" - for LD11 SoC
"socionext,uniphier-ld20-reset" - for LD20 SoC
+ "socionext,uniphier-pxs3-reset" - for PXs3 SoC
- #reset-cells: should be 1.
Example:
@@ -44,6 +45,7 @@ Required properties:
"socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO)
"socionext,uniphier-ld11-sd-reset" - for LD11 SoC (SD)
"socionext,uniphier-ld20-sd-reset" - for LD20 SoC
+ "socionext,uniphier-pxs3-sd-reset" - for PXs3 SoC
- #reset-cells: should be 1.
Example:
@@ -74,6 +76,7 @@ Required properties:
"socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC
"socionext,uniphier-ld11-peri-reset" - for LD11 SoC
"socionext,uniphier-ld20-peri-reset" - for LD20 SoC
+ "socionext,uniphier-pxs3-peri-reset" - for PXs3 SoC
- #reset-cells: should be 1.
Example:
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index bda2dd1..6ed808d 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -114,6 +114,20 @@ static const struct uniphier_reset_data uniphier_ld20_sys_reset_data[] = {
UNIPHIER_RESET_END,
};
+static const struct uniphier_reset_data uniphier_pxs3_sys_reset_data[] = {
+ UNIPHIER_RESETX(2, 0x200c, 0), /* NAND */
+ UNIPHIER_RESETX(4, 0x200c, 2), /* eMMC */
+ UNIPHIER_RESETX(8, 0x200c, 12), /* STDMAC */
+ UNIPHIER_RESETX(12, 0x200c, 4), /* USB30 link (GIO0) */
+ UNIPHIER_RESETX(13, 0x200c, 5), /* USB31 link (GIO1) */
+ UNIPHIER_RESETX(16, 0x200c, 16), /* USB30-PHY0 */
+ UNIPHIER_RESETX(17, 0x200c, 18), /* USB30-PHY1 */
+ UNIPHIER_RESETX(18, 0x200c, 20), /* USB30-PHY2 */
+ UNIPHIER_RESETX(20, 0x200c, 17), /* USB31-PHY0 */
+ UNIPHIER_RESETX(21, 0x200c, 19), /* USB31-PHY1 */
+ UNIPHIER_RESET_END,
+};
+
/* Media I/O reset data */
#define UNIPHIER_MIO_RESET_SD(id, ch) \
UNIPHIER_RESETX((id), 0x110 + 0x200 * (ch), 0)
@@ -359,6 +373,10 @@ static const struct of_device_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-ld20-reset",
.data = uniphier_ld20_sys_reset_data,
},
+ {
+ .compatible = "socionext,uniphier-pxs3-reset",
+ .data = uniphier_pxs3_sys_reset_data,
+ },
/* Media I/O reset, SD reset */
{
.compatible = "socionext,uniphier-ld4-mio-reset",
@@ -392,6 +410,10 @@ static const struct of_device_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-ld20-sd-reset",
.data = uniphier_pro5_sd_reset_data,
},
+ {
+ .compatible = "socionext,uniphier-pxs3-sd-reset",
+ .data = uniphier_pro5_sd_reset_data,
+ },
/* Peripheral reset */
{
.compatible = "socionext,uniphier-ld4-peri-reset",
@@ -421,6 +443,10 @@ static const struct of_device_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-ld20-peri-reset",
.data = uniphier_pro4_peri_reset_data,
},
+ {
+ .compatible = "socionext,uniphier-pxs3-peri-reset",
+ .data = uniphier_pro4_peri_reset_data,
+ },
/* Analog signal amplifiers reset */
{
.compatible = "socionext,uniphier-ld11-adamv-reset",
--
2.7.4
^ permalink raw reply related
* [PATCH] reset: uniphier: add PXs3 reset data
From: Masahiro Yamada @ 2017-10-05 2:30 UTC (permalink / raw)
To: linux-arm-kernel
Add basic reset data for Socionext's new SoC PXs3.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
.../devicetree/bindings/reset/uniphier-reset.txt | 3 +++
drivers/reset/reset-uniphier.c | 26 ++++++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
index 68a6f48..93efed6 100644
--- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
+++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
@@ -13,6 +13,7 @@ Required properties:
"socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC
"socionext,uniphier-ld11-reset" - for LD11 SoC
"socionext,uniphier-ld20-reset" - for LD20 SoC
+ "socionext,uniphier-pxs3-reset" - for PXs3 SoC
- #reset-cells: should be 1.
Example:
@@ -44,6 +45,7 @@ Required properties:
"socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO)
"socionext,uniphier-ld11-sd-reset" - for LD11 SoC (SD)
"socionext,uniphier-ld20-sd-reset" - for LD20 SoC
+ "socionext,uniphier-pxs3-sd-reset" - for PXs3 SoC
- #reset-cells: should be 1.
Example:
@@ -74,6 +76,7 @@ Required properties:
"socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC
"socionext,uniphier-ld11-peri-reset" - for LD11 SoC
"socionext,uniphier-ld20-peri-reset" - for LD20 SoC
+ "socionext,uniphier-pxs3-peri-reset" - for PXs3 SoC
- #reset-cells: should be 1.
Example:
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index bda2dd1..6ed808d 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -114,6 +114,20 @@ static const struct uniphier_reset_data uniphier_ld20_sys_reset_data[] = {
UNIPHIER_RESET_END,
};
+static const struct uniphier_reset_data uniphier_pxs3_sys_reset_data[] = {
+ UNIPHIER_RESETX(2, 0x200c, 0), /* NAND */
+ UNIPHIER_RESETX(4, 0x200c, 2), /* eMMC */
+ UNIPHIER_RESETX(8, 0x200c, 12), /* STDMAC */
+ UNIPHIER_RESETX(12, 0x200c, 4), /* USB30 link (GIO0) */
+ UNIPHIER_RESETX(13, 0x200c, 5), /* USB31 link (GIO1) */
+ UNIPHIER_RESETX(16, 0x200c, 16), /* USB30-PHY0 */
+ UNIPHIER_RESETX(17, 0x200c, 18), /* USB30-PHY1 */
+ UNIPHIER_RESETX(18, 0x200c, 20), /* USB30-PHY2 */
+ UNIPHIER_RESETX(20, 0x200c, 17), /* USB31-PHY0 */
+ UNIPHIER_RESETX(21, 0x200c, 19), /* USB31-PHY1 */
+ UNIPHIER_RESET_END,
+};
+
/* Media I/O reset data */
#define UNIPHIER_MIO_RESET_SD(id, ch) \
UNIPHIER_RESETX((id), 0x110 + 0x200 * (ch), 0)
@@ -359,6 +373,10 @@ static const struct of_device_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-ld20-reset",
.data = uniphier_ld20_sys_reset_data,
},
+ {
+ .compatible = "socionext,uniphier-pxs3-reset",
+ .data = uniphier_pxs3_sys_reset_data,
+ },
/* Media I/O reset, SD reset */
{
.compatible = "socionext,uniphier-ld4-mio-reset",
@@ -392,6 +410,10 @@ static const struct of_device_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-ld20-sd-reset",
.data = uniphier_pro5_sd_reset_data,
},
+ {
+ .compatible = "socionext,uniphier-pxs3-sd-reset",
+ .data = uniphier_pro5_sd_reset_data,
+ },
/* Peripheral reset */
{
.compatible = "socionext,uniphier-ld4-peri-reset",
@@ -421,6 +443,10 @@ static const struct of_device_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-ld20-peri-reset",
.data = uniphier_pro4_peri_reset_data,
},
+ {
+ .compatible = "socionext,uniphier-pxs3-peri-reset",
+ .data = uniphier_pro4_peri_reset_data,
+ },
/* Analog signal amplifiers reset */
{
.compatible = "socionext,uniphier-ld11-adamv-reset",
--
2.7.4
^ permalink raw reply related
* ✓ Fi.CI.IGT: success for igt/kms_rotation_crc: Add horizontal flip subtest.
From: Patchwork @ 2017-10-05 2:27 UTC (permalink / raw)
To: Anusha Srivatsa; +Cc: intel-gfx
In-Reply-To: <1507164223-22598-1-git-send-email-anusha.srivatsa@intel.com>
== Series Details ==
Series: igt/kms_rotation_crc: Add horizontal flip subtest.
URL : https://patchwork.freedesktop.org/series/31407/
State : success
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_299/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.