config FAT_FS tristate select NLS help If you want to use one of the FAT-based file systems (the MS-DOS and VFAT (Windows 95) file systems), then you must say Y or M here to include FAT support. You will then be able to mount partitions or diskettes with FAT-based file systems and transparently access the files on them, i.e. MSDOS files will look and behave just like all other Unix files. This FAT support is not a file system in itself, it only provides the foundation for the other file systems. You will have to say Y or M to at least one of "MSDOS fs support" or "VFAT fs support" in order to make use of it. Another way to read and write MSDOS floppies and hard drive partitions from within Linux (but not transparently) is with the mtools ("man mtools") program suite. You don't need to say Y here in order to do that. If you need to move large files on floppies between a DOS and a Linux box, say Y here, mount the floppy under Linux with an MSDOS file system and use GNU tar's M option. GNU tar is a program available for Unix and DOS ("man tar" or "info tar"). The FAT support will enlarge your kernel by about 37 KB. If unsure, say Y. To compile this as a module, choose M here: the module will be called fat. Note that if you compile the FAT support as a module, you cannot compile any of the FAT-based file systems into the kernel -- they will have to be modules as well. config MSDOS_FS tristate "MSDOS fs support" select FAT_FS help This allows you to mount MSDOS partitions of your hard drive (unless they are compressed; to access compressed MSDOS partitions under Linux, you can either use the DOS emulator DOSEMU, described in the DOSEMU-HOWTO, available from , or try dmsdosfs in . If you intend to use dosemu with a non-compressed MSDOS partition, say Y here) and MSDOS floppies. This means that file access becomes transparent, i.e. the MSDOS files look and behave just like all other Unix files. If you have Windows 95 or Windows NT installed on your MSDOS partitions, you should use the VFAT file system (say Y to "VFAT fs support" below), or you will not be able to see the long filenames generated by Windows 95 / Windows NT. This option will enlarge your kernel by about 7 KB. If unsure, answer Y. This will only work if you said Y to "DOS FAT fs support" as well. To compile this as a module, choose M here: the module will be called msdos. config VFAT_FS tristate "VFAT (Windows-95) fs support" select FAT_FS help This option provides support for normal Windows file systems with long filenames. That includes non-compressed FAT-based file systems used by Windows 95, Windows 98, Windows NT 4.0, and the Unix programs from the mtools package. The VFAT support enlarges your kernel by about 10 KB and it only works if you said Y to the "DOS FAT fs support" above. Please read the file for details. If unsure, say Y. To compile this as a module, choose M here: the module will be called vfat. config FAT_DEFAULT_CODEPAGE int "Default codepage for FAT" depends on MSDOS_FS || VFAT_FS default 437 help This option should be set to the codepage of your FAT filesystems. It can be overridden with the "codepage" mount option. See for more information. config FAT_DEFAULT_IOCHARSET string "Default iocharset for FAT" depends on VFAT_FS default "iso8859-1" help Set this to the default input/output character set you'd like FAT to use. It should probably match the character set that most of your FAT filesystems use, and can be overridden with the "iocharset" mount option for FAT filesystems. Note that "utf8" is not recommended for FAT filesystems. If unsure, you shouldn't set "utf8" here - select the next option instead if you would like to use UTF-8 encoded file names by default. See for more information. Enable any character sets you need in File Systems/Native Language Support. config FAT_DEFAULT_UTF8 bool "Enable FAT UTF-8 option by default" depends on VFAT_FS default n help Set this if you would like to have "utf8" mount option set by default when mounting FAT filesystems. Even if you say Y here can always disable UTF-8 for particular mount by adding "utf8=0" to mount options. Say Y if you use UTF-8 encoding for file names, N otherwise. See for more information. d>Mark Brown <broonie@kernel.org>2016-11-11 15:34:45 +0000 commit618c808968852609d2d9f0e5cfc351a4807ef8d0 (patch) tree01a8d928c06fe7bef488f55bade6ba37b958bb5f /net/openvswitch/Makefile parent1001354ca34179f3db924eb66672442a173147dc (diff)
regulator: axp20x: Fix axp809 ldo_io registration error on cold boot
The maximum supported voltage for ldo_io# is 3.3V, but on cold boot the selector comes up at 0x1f, which maps to 3.8V. This was previously corrected by Allwinner's U-boot, which set all regulators on the PMICs to some pre-configured voltage. With recent progress in U-boot SPL support, this is no longer the case. In any case we should handle this quirk in the kernel driver as well. This invalid setting causes _regulator_get_voltage() to fail with -EINVAL which causes regulator registration to fail when constrains are used: [ 1.054181] vcc-pg: failed to get the current voltage(-22) [ 1.059670] axp20x-regulator axp20x-regulator.0: Failed to register ldo_io0 [ 1.069749] axp20x-regulator: probe of axp20x-regulator.0 failed with error -22 This commits makes the axp20x regulator driver accept the 0x1f register value, fixing this. The datasheet does not guarantee reliable operation above 3.3V, so on boards where this regulator is used the regulator-max-microvolt setting must be 3.3V or less. This is essentially the same as the commit f40d4896bf32 ("regulator: axp20x: Fix axp22x ldo_io registration error on cold boot") for AXP22x PMICs. Fixes: a51f9f4622a3 ("regulator: axp20x: support AXP809 variant") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'net/openvswitch/Makefile')