/* * This header provides macros for MAXIM MAX77620 device bindings. * * Copyright (c) 2016, NVIDIA Corporation. * Author: Laxman Dewangan */ #ifndef _DT_BINDINGS_MFD_MAX77620_H #define _DT_BINDINGS_MFD_MAX77620_H /* MAX77620 interrupts */ #define MAX77620_IRQ_TOP_GLBL 0 /* Low-Battery */ #define MAX77620_IRQ_TOP_SD 1 /* SD power fail */ #define MAX77620_IRQ_TOP_LDO 2 /* LDO power fail */ #define MAX77620_IRQ_TOP_GPIO 3 /* GPIO internal int to MAX77620 */ #define MAX77620_IRQ_TOP_RTC 4 /* RTC */ #define MAX77620_IRQ_TOP_32K 5 /* 32kHz oscillator */ #define MAX77620_IRQ_TOP_ONOFF 6 /* ON/OFF oscillator */ #define MAX77620_IRQ_LBT_MBATLOW 7 /* Thermal alarm status, > 120C */ #define MAX77620_IRQ_LBT_TJALRM1 8 /* Thermal alarm status, > 120C */ #define MAX77620_IRQ_LBT_TJALRM2 9 /* Thermal alarm status, > 140C */ /* FPS event source */ #define MAX77620_FPS_EVENT_SRC_EN0 0 #define MAX77620_FPS_EVENT_SRC_EN1 1 #define MAX77620_FPS_EVENT_SRC_SW 2 /* Device state when FPS event LOW */ #define MAX77620_FPS_INACTIVE_STATE_SLEEP 0 #define MAX77620_FPS_INACTIVE_STATE_LOW_POWER 1 /* FPS source */ #define MAX77620_FPS_SRC_0 0 #define MAX77620_FPS_SRC_1 1 #define MAX77620_FPS_SRC_2 2 #define MAX77620_FPS_SRC_NONE 3 #define MAX77620_FPS_SRC_DEF 4 #endif rx-pump-back'>packet-rx-pump-back net-next plumbingsTobias Klauser
summaryrefslogtreecommitdiff
path: root/include/trace/events
diff options
context:
space:
mode:
authorColy Li <colyli@suse.de>2017-01-24 15:18:46 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2017-01-24 16:26:14 -0800
commitf598f82e204ec0b17797caaf1b0311c52d43fb9a (patch)
tree20e0109db50c168a36df14af76b484eaf9b71836 /include/trace/events
parent4180c4c170a5a33b9987b314d248a9d572d89ab0 (diff)
romfs: use different way to generate fsid for BLOCK or MTD
Commit 8a59f5d25265 ("fs/romfs: return f_fsid for statfs(2)") generates a 64bit id from sb->s_bdev->bd_dev. This is only correct when romfs is defined with CONFIG_ROMFS_ON_BLOCK. If romfs is only defined with CONFIG_ROMFS_ON_MTD, sb->s_bdev is NULL, referencing sb->s_bdev->bd_dev will triger an oops. Richard Weinberger points out that when CONFIG_ROMFS_BACKED_BY_BOTH=y, both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD are defined. Therefore when calling huge_encode_dev() to generate a 64bit id, I use the follow order to choose parameter, - CONFIG_ROMFS_ON_BLOCK defined use sb->s_bdev->bd_dev - CONFIG_ROMFS_ON_BLOCK undefined and CONFIG_ROMFS_ON_MTD defined use sb->s_dev when, - both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD undefined leave id as 0 When CONFIG_ROMFS_ON_MTD is defined and sb->s_mtd is not NULL, sb->s_dev is set to a device ID generated by MTD_BLOCK_MAJOR and mtd index, otherwise sb->s_dev is 0. This is a try-best effort to generate a uniq file system ID, if all the above conditions are not meet, f_fsid of this romfs instance will be 0. Generally only one romfs can be built on single MTD block device, this method is enough to identify multiple romfs instances in a computer. Link: http://lkml.kernel.org/r/1482928596-115155-1-git-send-email-colyli@suse.de Signed-off-by: Coly Li <colyli@suse.de> Reported-by: Nong Li <nongli1031@gmail.com> Tested-by: Nong Li <nongli1031@gmail.com> Cc: Richard Weinberger <richard.weinberger@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/trace/events')