Re: BUG: pagefault on kernel address ADDR in non-whitelisted uaccess
syzbot has found a reproducer for the following crash on: HEAD commit:5f21585384a4 Merge tag 'for-linus-20181102' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=103c982540 kernel config: https://syzkaller.appspot.com/x/.config?x=9384ecb1c973baed dashboard link: https://syzkaller.appspot.com/bug?extid=0cc8e3cc63ca373722c6 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=112736eb40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14e2d82b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+0cc8e3cc63ca37372...@syzkaller.appspotmail.com sshd (5636) used greatest stack depth: 15744 bytes left BUG: pagefault on kernel address 0xc90002569000 in non-whitelisted uaccess BUG: unable to handle kernel paging request at c90002569000 PGD 1da948067 P4D 1da948067 PUD 1da949067 PMD 1c0211067 PTE 0 Oops: [#1] PREEMPT SMP KASAN CPU: 0 PID: 5650 Comm: syz-executor571 Not tainted 4.19.0+ #317 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:copy_user_enhanced_fast_string+0xe/0x20 arch/x86/lib/copy_user_64.S:180 Code: 89 d1 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 31 c0 0f 1f 00 c3 0f 1f 80 00 00 00 00 0f 1f 00 83 fa 40 0f 82 70 ff ff ff 89 d1 a4 31 c0 0f 1f 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 83 RSP: 0018:8801d8fcf680 EFLAGS: 00010202 RAX: RBX: ca80 RCX: 4a80 RDX: ca80 RSI: c90002569000 RDI: 200080c0 RBP: 8801d8fcf6b8 R08: R09: 032a R10: f520004adb4f R11: c9000256da7f R12: 2000cb40 R13: 20c0 R14: c90002561000 R15: 7000 FS: 017ca880() GS:8801dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c90002569000 CR3: 0001ba5d7000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: copy_to_user include/linux/uaccess.h:155 [inline] vidioc_g_fmt_vid_overlay+0x392/0x550 drivers/media/platform/vivid/vivid-vid-cap.c:1084 v4l_g_fmt+0x2ad/0x640 drivers/media/v4l2-core/v4l2-ioctl.c:1489 __video_do_ioctl+0x8b1/0x1050 drivers/media/v4l2-core/v4l2-ioctl.c:2853 video_usercopy+0x5c1/0x1760 drivers/media/v4l2-core/v4l2-ioctl.c:3035 video_ioctl2+0x2c/0x33 drivers/media/v4l2-core/v4l2-ioctl.c:3079 v4l2_ioctl+0x154/0x1b0 drivers/media/v4l2-core/v4l2-dev.c:364 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x443f49 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fffbe4a44c8 EFLAGS: 0217 ORIG_RAX: 0010 RAX: ffda RBX: 004002e0 RCX: 00443f49 RDX: 20c0 RSI: c0d05604 RDI: 0004 RBP: 006ce018 R08: 004002e0 R09: 004002e0 R10: 004002e0 R11: 0217 R12: 00401c50 R13: 00401ce0 R14: R15: Modules linked in: CR2: c90002569000 ---[ end trace e294d16803c6d199 ]--- RIP: 0010:copy_user_enhanced_fast_string+0xe/0x20 arch/x86/lib/copy_user_64.S:180 Code: 89 d1 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 31 c0 0f 1f 00 c3 0f 1f 80 00 00 00 00 0f 1f 00 83 fa 40 0f 82 70 ff ff ff 89 d1 a4 31 c0 0f 1f 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 83 RSP: 0018:8801d8fcf680 EFLAGS: 00010202 RAX: RBX: ca80 RCX: 4a80 RDX: ca80 RSI: c90002569000 RDI: 200080c0 RBP: 8801d8fcf6b8 R08: R09: 032a R10: f520004adb4f R11: c9000256da7f R12: 2000cb40 R13: 20c0 R14: c90002561000 R15: 7000 FS: 017ca880() GS:8801dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c90002569000 CR3: 0001ba5d7000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
Re: [PATCH 2/7] dt-bindings: mfd: ds90ux9xx: add description of TI DS90Ux9xx I2C bridge
Hi Vladimir, On 31/10/18 21:12, Vladimir Zapolskiy wrote: > Hi Luca, > > thank you for review. > > On 10/30/2018 06:43 PM, Luca Ceresoli wrote: >> Hi Vladimir, >> >> On 08/10/18 23:12, Vladimir Zapolskiy wrote: >>> From: Vladimir Zapolskiy >>> >>> TI DS90Ux9xx de-/serializers are capable to route I2C messages to >>> I2C slave devices connected to a remote de-/serializer in a pair, >>> the change adds description of device tree bindings of the subcontroller >>> to configure and enable this functionality. >>> >>> Signed-off-by: Vladimir Zapolskiy >>> --- >>> .../bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt | 61 +++ >>> 1 file changed, 61 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt >>> >>> diff --git >>> a/Documentation/devicetree/bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt >>> b/Documentation/devicetree/bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt >>> new file mode 100644 >>> index ..4169e382073a >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt >>> @@ -0,0 +1,61 @@ >>> +TI DS90Ux9xx de-/serializer I2C bridge subcontroller >>> + >>> +Required properties: >>> +- compatible: Must contain a generic "ti,ds90ux9xx-i2c-bridge" value and >>> + may contain one more specific value from the list: >>> + "ti,ds90ux925-i2c-bridge", >>> + "ti,ds90ux926-i2c-bridge", >>> + "ti,ds90ux927-i2c-bridge", >>> + "ti,ds90ux928-i2c-bridge", >>> + "ti,ds90ux940-i2c-bridge". >>> + >>> +Required properties of a de-/serializer device connected to a local I2C >>> bus: >>> +- ti,i2c-bridges: List of phandles to remote de-/serializer devices with >>> + two arguments: id of a local de-/serializer FPD link and an assigned >>> + I2C address of a remote de-/serializer to be accessed on a local >>> + I2C bus. >>> + >>> +Optional properties of a de-/serializer device connected to a local I2C >>> bus: >>> +- ti,i2c-bridge-maps: List of 3-cell values: >>> + - the first argument is id of a local de-/serializer FPD link, >>> + - the second argument is an I2C address of a device connected to >>> + a remote de-/serializer IC, >>> + - the third argument is an I2C address of the remote I2C device >>> + for access on a local I2C bus. >> >> BTW I usually use names "remove slave" address and "alias" for bullets 2 >> and 3. These are the names from the datasheets, and are clearer IMO. >> > > Definitely you are correct, I find that verbose descriptions might be > more appropriate and self-explanatory for anyone, who is not closely familiar > with the IC series. I'll consider to add the names from the datasheets > as well. > >> Now to the big stuff. >> >> I find a static map in the "local" chip DT node is a limit. You might >> have to support multiple models of remote device, where you'll know the >> model only when after it gets connected. Think Beaglebone capes, but >> over FPD-Link 3. This scenario opens several issues, but specifically >> for I2C address mapping I addressed it by adding in the "local" chip's >> DT node a pool of I2C aliases it can use. The DT author is responsible >> to pick addresses that are not used on the same I2C bus, which cannot be >> done at runtime reliably. > > Here I see several important topics raised. > > 1) A static map in the "local" chip DT node is not a limit in sense that >it is optional, so it would be a working model just to omit the property, >however it may (or may not) require another handlers to bridge remote >I2C devices, for instance 'ti,i2c-bridge-pass-all' property, or new >UAPI. Do you mean when the "pass-all" method and the "static map in the local node" method are insufficient, then the solution is to implement a third method that is powerful enough? If that's what you mean, then I think we should rather [try to] implement from the beginning a method that is powerful enough to handle all the cases we can foresee. > 2) About supporting multiple models of remote PCBs in the same dts file, >it might be an excessive complication to predict a proper description >of an unknown in advance complex device, so, a better solution should >be to apply DT overlays in runtime, but at any time the hardware >description and the mapping shall be precisely defined. I agree runtime DT overlays is the correct way of handling multiple remote boards, but not if they contain a ti,i2c-bridge-maps (physical-to-alias I2C address map). Consider the case where we have N different main board (with SoC and "local" [de]serializer) and M peripheral boards (display+deserializer or sensor+serializer). Then we'd need up to N*M DT overlays, each with the alias map for a specific pair. This is because the map maps a physical address that exists on the remote side (peripheral board) to an alias that exists on the local side (main board). To realistically model the hardware, the DT overlay should contain the removable components, including
Re: [PATCH 2/7] dt-bindings: mfd: ds90ux9xx: add description of TI DS90Ux9xx I2C bridge
Hi Luca, On 11/03/2018 11:00 PM, Luca Ceresoli wrote: > Hi Vladimir, > > On 31/10/18 21:12, Vladimir Zapolskiy wrote: >> Hi Luca, >> >> thank you for review. >> >> On 10/30/2018 06:43 PM, Luca Ceresoli wrote: >>> Hi Vladimir, >>> >>> On 08/10/18 23:12, Vladimir Zapolskiy wrote: From: Vladimir Zapolskiy TI DS90Ux9xx de-/serializers are capable to route I2C messages to I2C slave devices connected to a remote de-/serializer in a pair, the change adds description of device tree bindings of the subcontroller to configure and enable this functionality. Signed-off-by: Vladimir Zapolskiy --- .../bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt | 61 +++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt diff --git a/Documentation/devicetree/bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt b/Documentation/devicetree/bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt new file mode 100644 index ..4169e382073a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ti,ds90ux9xx-i2c-bridge.txt @@ -0,0 +1,61 @@ +TI DS90Ux9xx de-/serializer I2C bridge subcontroller + +Required properties: +- compatible: Must contain a generic "ti,ds90ux9xx-i2c-bridge" value and + may contain one more specific value from the list: + "ti,ds90ux925-i2c-bridge", + "ti,ds90ux926-i2c-bridge", + "ti,ds90ux927-i2c-bridge", + "ti,ds90ux928-i2c-bridge", + "ti,ds90ux940-i2c-bridge". + +Required properties of a de-/serializer device connected to a local I2C bus: +- ti,i2c-bridges: List of phandles to remote de-/serializer devices with + two arguments: id of a local de-/serializer FPD link and an assigned + I2C address of a remote de-/serializer to be accessed on a local + I2C bus. + +Optional properties of a de-/serializer device connected to a local I2C bus: +- ti,i2c-bridge-maps: List of 3-cell values: + - the first argument is id of a local de-/serializer FPD link, + - the second argument is an I2C address of a device connected to +a remote de-/serializer IC, + - the third argument is an I2C address of the remote I2C device +for access on a local I2C bus. >>> >>> BTW I usually use names "remove slave" address and "alias" for bullets 2 >>> and 3. These are the names from the datasheets, and are clearer IMO. >>> >> >> Definitely you are correct, I find that verbose descriptions might be >> more appropriate and self-explanatory for anyone, who is not closely familiar >> with the IC series. I'll consider to add the names from the datasheets >> as well. >> >>> Now to the big stuff. >>> >>> I find a static map in the "local" chip DT node is a limit. You might >>> have to support multiple models of remote device, where you'll know the >>> model only when after it gets connected. Think Beaglebone capes, but >>> over FPD-Link 3. This scenario opens several issues, but specifically >>> for I2C address mapping I addressed it by adding in the "local" chip's >>> DT node a pool of I2C aliases it can use. The DT author is responsible >>> to pick addresses that are not used on the same I2C bus, which cannot be >>> done at runtime reliably. >> >> Here I see several important topics raised. >> >> 1) A static map in the "local" chip DT node is not a limit in sense that >>it is optional, so it would be a working model just to omit the property, >>however it may (or may not) require another handlers to bridge remote >>I2C devices, for instance 'ti,i2c-bridge-pass-all' property, or new >>UAPI. > > Do you mean when the "pass-all" method and the "static map in the local > node" method are insufficient, then the solution is to implement a third > method that is powerful enough? If that's what you mean, then I think we > should rather [try to] implement from the beginning a method that is > powerful enough to handle all the cases we can foresee. To my best knowledge "static map in the local node" method from my design is completely sufficient alone. On top of it, if hardware design of a series of remote PCBs is thought-out enough, then adding DT overlays allows to manage connections and instantiatings of unknown in advance remote PCBs in runtime, but this is out of scope of classic IC device tree design, because device trees are for description of non-discoverable hardware, thus clearly a complex PCB behind an FPD-Link III shall find its description in DTB in more or less precise way. PASS ALL setting may be helpful for testing or adding initial support of remote PCBs, by the way I've recollected that ICs support simultaneous slave/alias mappings and PASS ALL function, the practical sense is not clear though. >> 2) About supporting multiple models of remote PCBs in the same dts file, >>it might be an excessive c
Re: linux-next: Tree for Nov 2 (compiler-gcc.h)
On Sat, Nov 3, 2018 at 5:10 PM Randy Dunlap wrote:
>
> No plugins are enabled.
> The failing randconfig file (for x86_64) is attached.
Confirmed with a built-from-sources 4.8.5 on current master
(d2ff0ff2c23f). The ICE also happens with 4.6.4. With 8.1.0, however,
we get an error instead:
In file included from drivers/media/usb/dvb-usb/pctv452e.c:20:
drivers/media/usb/dvb-usb/pctv452e.c: In function 'pctv452e_frontend_attach':
./drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak
declaration of 'stb0899_attach' being applied to a already existing,
static definition
static inline struct dvb_frontend *stb0899_attach(struct
stb0899_config *config,
^~
Which seems to have been spotted by kbuild months ago:
https://lkml.org/lkml/2018/3/10/358
The problem is in pctv452e_frontend_attach():
/*
* dvb_frontend will call dvb_detach for both stb0899_detach
* and stb0899_release but we only do dvb_attach(stb0899_attach).
* Increment the module refcount instead.
*/
symbol_get(stb0899_attach);
Here symbol_get() is declaring a weak function (due to
!CONFIG_MODULES) while this definition in stb0899_drv.h occurs (due to
!CONFIG_DVB_STB0899):
static inline struct dvb_frontend *stb0899_attach(struct stb0899_config *config,
struct i2c_adapter *i2c)
{
printk(KERN_WARNING "%s: Driver disabled by Kconfig\n", __func__);
return NULL;
}
I guess pctv452e should require CONFIG_DVB_STB0899, or similar. CC'ing
Mauro, Wolfgang, linux-media.
Hope that helps!
Cheers,
Miguel
Re: linux-next: Tree for Nov 2 (compiler-gcc.h)
On 11/3/18 3:58 PM, Miguel Ojeda wrote:
> On Sat, Nov 3, 2018 at 5:10 PM Randy Dunlap wrote:
>>
>> No plugins are enabled.
>> The failing randconfig file (for x86_64) is attached.
>
> Confirmed with a built-from-sources 4.8.5 on current master
> (d2ff0ff2c23f). The ICE also happens with 4.6.4. With 8.1.0, however,
> we get an error instead:
>
> In file included from drivers/media/usb/dvb-usb/pctv452e.c:20:
> drivers/media/usb/dvb-usb/pctv452e.c: In function 'pctv452e_frontend_attach':
> ./drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak
> declaration of 'stb0899_attach' being applied to a already existing,
> static definition
> static inline struct dvb_frontend *stb0899_attach(struct
> stb0899_config *config,
> ^~
>
> Which seems to have been spotted by kbuild months ago:
>
> https://lkml.org/lkml/2018/3/10/358
>
> The problem is in pctv452e_frontend_attach():
>
> /*
> * dvb_frontend will call dvb_detach for both stb0899_detach
> * and stb0899_release but we only do dvb_attach(stb0899_attach).
> * Increment the module refcount instead.
> */
> symbol_get(stb0899_attach);
>
> Here symbol_get() is declaring a weak function (due to
> !CONFIG_MODULES) while this definition in stb0899_drv.h occurs (due to
> !CONFIG_DVB_STB0899):
>
> static inline struct dvb_frontend *stb0899_attach(struct stb0899_config
> *config,
> struct i2c_adapter *i2c)
> {
> printk(KERN_WARNING "%s: Driver disabled by Kconfig\n", __func__);
> return NULL;
> }
>
> I guess pctv452e should require CONFIG_DVB_STB0899, or similar. CC'ing
> Mauro, Wolfgang, linux-media.
>
> Hope that helps!
Thanks for digging into this. :)
cheers.
--
~Randy
Re: linux-next: Tree for Nov 2 (compiler-gcc.h)
On Sun, Nov 4, 2018 at 12:01 AM Randy Dunlap wrote: > > Thanks for digging into this. :) You're welcome! You startled me a bit when I saw compiler-gcc.h/compiler_types.h there ;) Cheers, Miguel
Re: [PATCH] Input: Add missing event codes for common IR remote buttons
Hi Derek, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on input/next] [also build test WARNING on v4.19 next-20181102] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Derek-Kelly/Input-Add-missing-event-codes-for-common-IR-remote-buttons/20181103-135217 base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next config: powerpc-defconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=powerpc All warnings (new ones prefixed by >>): In file included from sound/ppc/pmac.h:39:0, from sound/ppc/beep.c:30: >> arch/powerpc/include/asm/dbdma.h:70:0: warning: "KEY_SYSTEM" redefined #define KEY_SYSTEM 0x600 /* system memory-mapped space */ In file included from include/uapi/linux/input.h:20:0, from include/linux/input.h:13, from sound/ppc/beep.c:25: include/uapi/linux/input-event-codes.h:698:0: note: this is the location of the previous definition #define KEY_SYSTEM 0x2ed /* Open systems menu/display */ vim +/KEY_SYSTEM +70 arch/powerpc/include/asm/dbdma.h ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 63 ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 64 /* Key values in command field */ ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 65 #define KEY_STREAM0 0 /* usual data stream */ ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 66 #define KEY_STREAM1 0x100 /* control/status stream */ ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 67 #define KEY_STREAM2 0x200 /* device-dependent stream */ ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 68 #define KEY_STREAM3 0x300 /* device-dependent stream */ ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 69 #define KEY_REGS0x500 /* device register space */ ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 @70 #define KEY_SYSTEM 0x600 /* system memory-mapped space */ ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 71 #define KEY_DEVICE 0x700 /* device memory-mapped space */ ^1da177e include/asm-ppc/dbdma.h Linus Torvalds 2005-04-16 72 :: The code at line 70 was first introduced by commit :: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2 :: TO: Linus Torvalds :: CC: Linus Torvalds --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Mygica T230 DVB-T/T2/C usb fails constantly with bulk errors
Greetings, I ave a Mygica T230 DVB-T/T2/C usb dongle which I use to view dvb broadcasting. it seems that after a sometime, the device stops working and fills dmesg with the following errors: bulk message failed: -110 (1/0) only tvheadend stop + device removal resets the device but the issue resurfaces later on. I've tried the device on two different systems and three kernels, all shows the same issue. x64 debian with kernels 4.15 and 4.18 and rpi2 with 4.14.70-v7+ is there any known solution for this issue? thanks, Dagg.
[PATCH] staging:media:Add SPDX-License-Identifier
Add SPDX-License-Identifier to fix missing license tag checkpatch warning Signed-off-by: Irenge Jules Bashizi --- drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h b/drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h index 7cc115c9ebe6..6d2570a63529 100644 --- a/drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h +++ b/drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (C) 2012 Texas Instruments Inc * @@ -10,9 +11,6 @@ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * * Contributors: * Manjunath Hadli -- 2.17.2
[PATCH v2] Input: Add missing event codes for common IR remote buttons
The following patch adds event codes for common buttons found on various provider and universal remote controls. They represent functions not covered by existing event codes. Once added, rc_keymaps can be updated accordingly where applicable. v2 changes: Renamed KEY_SYSTEM to KEY_SYSTEM_MENU to avoid conflict with powerpc KEY_SYSTEM define. Signed-off-by: Derek Kelly --- include/uapi/linux/input-event-codes.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 53fbae27b280..a15fd3c944d2 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -689,6 +689,19 @@ #define BTN_TRIGGER_HAPPY390x2e6 #define BTN_TRIGGER_HAPPY400x2e7 +/* Remote control buttons found across provider & universal remotes */ +#define KEY_LIVE_TV0x2e8 /* Jump to live tv viewing */ +#define KEY_OPTIONS0x2e9 /* Jump to options */ +#define KEY_INTERACTIVE0x2ea /* Jump to interactive system/menu/item */ +#define KEY_MIC_INPUT 0x2eb /* Trigger MIC input/listen mode */ +#define KEY_SCREEN_INPUT 0x2ec /* Open on-screen input system */ +#define KEY_SYSTEM_MENU0x2ed /* Open systems menu/display */ +#define KEY_SERVICES 0x2ee /* Access services */ +#define KEY_DISPLAY_FORMAT 0x2ef /* Cycle display formats */ +#define KEY_PIP0x2f0 /* Toggle Picture-in-Picture on/off */ +#define KEY_PIP_SWAP 0x2f1 /* Swap contents between main view and PIP window */ +#define KEY_PIP_POSITION 0x2f2 /* Cycle PIP window position */ + /* We avoid low common keys in module aliases so they don't get huge. */ #define KEY_MIN_INTERESTINGKEY_MUTE #define KEY_MAX0x2ff -- 2.19.1
Re: [Outreachy kernel] [PATCH] staging:media:Add SPDX-License-Identifier
On Sat, Nov 03, 2018 at 11:16:48AM +, Irenge Jules Bashizi wrote: > Add SPDX-License-Identifier to fix missing license tag checkpatch warning > > Signed-off-by: Irenge Jules Bashizi > --- > drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h > b/drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h > index 7cc115c9ebe6..6d2570a63529 100644 > --- a/drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h > +++ b/drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h > @@ -1,3 +1,4 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > /* > * Copyright (C) 2012 Texas Instruments Inc > * > @@ -10,9 +11,6 @@ > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > * GNU General Public License for more details. > * > - * You should have received a copy of the GNU General Public License > - * along with this program; if not, write to the Free Software > - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Read Documentation/process/license-rules.rst and try to understand why SPDX was introduced ? Hint: search for "boilerplate" in license-rules.rst Or search for previosuly accepted patches on SPDX ... -- Himanshu Jha Undergraduate Student Department of Electronics & Communication Guru Tegh Bahadur Institute of Technology
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Nov 4 05:00:11 CET 2018 media-tree git hash:dafb7f9aef2fd44991ff1691721ff765a23be27b media_build git hash: 0c8bb27f3aaa682b9548b656f77505c3d1f11e71 v4l-utils git hash: c36dbbdfa8b30b2badd4f893b59d0bd4f0bd12aa edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: WARNINGS linux-git-arm-stm32: WARNINGS linux-git-arm64: OK linux-git-i686: WARNINGS linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-sh: OK linux-git-x86_64: WARNINGS Check COMPILE_TEST: OK linux-3.10.108-i686: ERRORS linux-3.10.108-x86_64: ERRORS linux-3.11.10-i686: ERRORS linux-3.11.10-x86_64: ERRORS linux-3.12.74-i686: ERRORS linux-3.12.74-x86_64: ERRORS linux-3.13.11-i686: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.79-i686: ERRORS linux-3.14.79-x86_64: ERRORS linux-3.15.10-i686: ERRORS linux-3.15.10-x86_64: ERRORS linux-3.16.57-i686: ERRORS linux-3.16.57-x86_64: ERRORS linux-3.17.8-i686: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.123-i686: ERRORS linux-3.18.123-x86_64: ERRORS linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.52-i686: ERRORS linux-4.1.52-x86_64: ERRORS linux-4.2.8-i686: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-i686: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.159-i686: ERRORS linux-4.4.159-x86_64: ERRORS linux-4.5.7-i686: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-i686: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.10-i686: ERRORS linux-4.7.10-x86_64: ERRORS linux-4.8.17-i686: ERRORS linux-4.8.17-x86_64: ERRORS linux-4.9.131-i686: ERRORS linux-4.9.131-x86_64: ERRORS linux-4.10.17-i686: ERRORS linux-4.10.17-x86_64: ERRORS linux-4.11.12-i686: ERRORS linux-4.11.12-x86_64: ERRORS linux-4.12.14-i686: ERRORS linux-4.12.14-x86_64: ERRORS linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19-i686: OK linux-4.19-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Logs weren't copied as they are too large (1704 kB) The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
