- 19 May, 2012 4 commits
-
-
Shawn Guo authored
It fixes the issue in gpio-generic that commit fb149218 (gpio/mxc: add missing initialization of basic_mmio_gpio shadow variables) manged to fix in gpio-mxc driver, so that other platform specific drivers do not suffer from the same problem over and over again. Changes since v1: * Turn the last parameter of bgpio_init() "bool big_endian" into "unsigned long flags" and give those really quirky hardwares a chance to tell that reg_set and reg_dir are unreadable. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> [grant.likely: Fix big-endian usage to explicitly set BBGPIOF_BIG_ENDIAN] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Grant Likely authored
Commit 3d0f7cf0 "gpio: Adjust of_xlate API to support multiple GPIO chips" changed the api of gpiochip_find to drop const from the data parameter of the match hook, but didn't also drop const from data causing a build warning. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Laxman Dewangan authored
The PMIC device RC5T583 from RICOH supports 8 gpios. Adding gpio driver for this device to access the pins control through gpio library. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> [grant.likely: slight cosmetic changes] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
H Hartley Sweeten authored
The pr_info message in gpiochip_add gets displayed for every gpiochip registered. When first bringing up a system this information could be helpful but for normal use it's just a bunch of noise. Change the message to a pr_debug. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
- 18 May, 2012 9 commits
-
-
Grant Likely authored
Merge branch 'for_3.5/fixes/gpio-2' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into gpio/next
-
Thomas Gleixner authored
commit cfadd838(powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO driver) added an unconditional call of chip->irq_eoi() to the demux handler. This leads to a NULL pointer derefernce on MPC512x platforms which use this driver as well. Make it conditional. Reported-by: Thomas Wucher <thwucher@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Felix Radensky <felix@embedded-sol.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: stable@vger.kernel.org Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Roland Stigge authored
This patch adds device tree support for gpio-lpc32xx.c. To register the various GPIO banks as (struct) gpio_chips via the same DT gpio-controller, we utilize the adjusted of_xlate API to manipulate the actually used struct gpio_chip. Signed-off-by: Roland Stigge <stigge@antcom.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Grant Likely authored
This patch changes the of_xlate API to make it possible for multiple gpio_chips to refer to the same device tree node. This is useful for banked GPIO controllers that use multiple gpio_chips for a single device. With this change the core code will try calling of_xlate on each gpio_chip that references the device_node and will return the gpio number for the first one to return 'true'. Tested-by: Roland Stigge <stigge@antcom.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Mark Brown authored
Allow drivers to use the modern request and configure idiom together with devres. As with plain gpio_request() and gpio_request_one() we can't implement the old school version in terms of _one() as this would force the explicit selection of a direction in gpio_request() which could break systems if we pick the wrong one. Implementing devm_gpio_request_one() in terms of devm_gpio_request() would needlessly complicate things or lead to duplication from the unmanaged version depending on how it's done. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Peter Korsgaard authored
Pullups are enabled when bits are set, not when cleared. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Andreas Schallenberg authored
This patch extends the PCA953x driver to support TI's TCA6424A 24 bit I2C I/O expander. The patch is based on code by Michele Bevilacqua. Changes in v2: - Compare ngpio against 24 in both places, not >16 - Larger datatype now u32 instead of uint. Bit fields not used for struct members since their address is taken. - Be precise: TCA6424A (untested for older TCA6424) Signed-off-by: Andreas Schallenberg<Andreas.Schallenberg@3alitytechnica.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Kevin Hilman authored
commit 1b128703 (gpio/omap: fix missing check in *_runtime_suspend()) broke wakeups on level-triggered GPIOs by adding the enabled non-wakeup GPIO check before the workaround that enables wakeups on level-triggered IRQs, effectively disabling that workaround. To fix, move the enabled non-wakeup GPIO check after the level-triggered IRQ workaround. Reported-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Tested-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Kevin Hilman authored
The fix in commit 1b128703 (gpio/omap: fix missing check in *_runtime_suspend()) exposed another bug in the context restore path. Currently, the per-bank context restore happens whenever the context loss count is different in runtime suspend and runtime resume *and* whenever the per-bank contex_loss_count == 0: if (context_lost_cnt_after != bank->context_loss_count || !context_lost_cnt_after) { omap_gpio_restore_context(bank); Restoring context when the context_lost_cnt_after == 0 is clearly wrong, since this will be true until the first off-mode transition (which could be never, if off-mode is never enabled.) This check causes the context to be restored on *every* runtime PM transition. Before commit 1b128703 (gpio/omap: fix missing check in *_runtime_suspend()), this code was never executed in non-OFF mode, so there were never spurious context restores happening. After that change though, spurious context restores could happen. To fix, simply remove the !context_lost_cnt_after check. It is not needed. This bug was found when noticing that the smc911x NIC on 3530/Overo was not working, and git bisect tracked it down to this patch. It seems that the spurious context restore was causing the smsc911x to not be properly probed on this platform. Tested-by: Tony Lindgren <tony@atomide.com> Acked-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
- 12 May, 2012 10 commits
-
-
Grant Likely authored
Merge branch 'for_3.5/gpio/cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into gpio/next
-
Tarun Kanti DebBarma authored
We do checking for bank->enabled_non_wakeup_gpios in order to skip redundant operations. Somehow, the check got missed while doing the cleanup series. Just to make sure that we do context restore correctly in *_runtime_resume(), the bank->workaround_enabled check is moved after context restore. Otherwise, it would prevent context restore when bank->enabled_non_wakeup_gpios is 0. Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Tarun Kanti DebBarma authored
Add register offsets for GPIO_IRQSTATUS_RAW_0, GPIO_IRQSTATUS_RAW_0 which are present on OMAP4+ processors. Now we can distinguish conditions applicable to OMAP4,5 and those specific to OMAP24xx and OMAP3xxx. Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Tarun Kanti DebBarma authored
Both omap_gpio_suspend() and omap_gpio_resume() does programming of wakeup_en register. _gpio_rmw(base, bank->regs->wkup_en, 0xffffffff, 0); _gpio_rmw(base, bank->regs->wkup_en, bank->context.wake_en, 1); This is redundant in omap_gpio_suspend() because wakeup_en register automatically gets initialized in _set_gpio_wakeup() and set_gpio_trigger() while being called either from chip.irq_set_wake() or chip.irq_set_type(). This is also redundant in omap_gpio_resume() because wakeup_en register is programmed in omap_gpio_restore_context() called which is called from runtime resume callback. Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Tarun Kanti DebBarma authored
commit 672e302e (ARM: OMAP: use edge/level handlers from generic IRQ framework) removed retrigger support in favor of using generic IRQ framework. This patch cleans up some unused remnants of that removal. Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Tested-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Tarun Kanti DebBarma authored
There is no more need to have saved_wakeup because bank->context.wake_en already holds that value. So getting rid of read/write operation associated with this field. Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Tested-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Tarun Kanti DebBarma authored
Since we already have bank->context.wake_en to keep track of gpios which are wakeup enabled, there is no need to have this field any more. Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Tested-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Tarun Kanti DebBarma authored
Since we already have context.fallingdetect and context.risingdetect there is no more need to have these additional fields. Also, getting rid of extra reads associated with them. Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Tested-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Tarun Kanti DebBarma authored
This cleanup got missed while implementing following: 25db711d gpio/omap: Fix IRQ handling for SPARSE_IRQ 384ebe1c gpio/omap: Add DT support to GPIO driver Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Mark Brown authored
Rather than requiring architectures that use gpiolib but don't have any need to define anything custom to copy an asm/gpio.h provide a Kconfig symbol which architectures must select in order to include gpio.h and for other architectures just provide the trivial implementation directly. This makes it much easier to do gpiolib updates and is also a step towards making gpiolib APIs available on every architecture. For architectures with existing boilerplate code leave a stub header in place which warns on direct inclusion of asm/gpio.h and includes linux/gpio.h to catch code that's doing this. Direct inclusion of asm/gpio.h has long been deprecated. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Jonas Bonn <jonas@southpole.se> Acked-by: Tony Luck <tony.luck@intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
- 11 May, 2012 2 commits
-
-
Mathias Nyman authored
Add gpio support for Intel MSIC chips found in Intel Medfield platforms. MSIC supports totally 24 GPIOs with 16 low voltage and 8 high voltage pins. Driver uses MSIC mfd interface for MSIC access. (Updated comment to indicate why locking is actually safe) Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Olof Johansson authored
Only code move, no functional change. Main reason to do this was to get rid of the warnings: drivers/gpio/gpio-samsung.c: In function 'samsung_gpiolib_init': drivers/gpio/gpio-samsung.c:2974:1: warning: label 'err_ioremap4' defined but not used [-Wunused-label] drivers/gpio/gpio-samsung.c:2722:47: warning: unused variable 'gpio_base4' [-Wunused-variable] without adding more ifdef mess. I think this whole file would do well being coverted over to a platform driver and moving most of the tables out to SoC code and/or device trees, but since that changes init ordering it needs to be done with some care, i.e. not at this time. Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
- 10 May, 2012 2 commits
-
-
Mika Westerberg authored
The IRQ status register should be re-read after each iteration. Otherwise the loop misses the interrupt if it gets raised immediately after handled. Reported-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Tarun Kanti DebBarma authored
Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced wrongly to take care of OMAP2+ platforms were overwriting initially programmed OMAP1 value breaking functionality on OMAP1. Somehow incorrect assumption was made that each _gpio_rmw()'s were mutually exclusive. On close observation it is found that the first _gpio_rmw() which is supposedly done to take care of OMAP1 platform is generic enough and takes care of OMAP2+ platform as well. Therefore remove the latter _gpio_rmw() to irqenable as they are redundant now. Writing to ctrl and debounce_en registers for OMAP2+ platforms are modified to match the original(pre-cleanup) code where the registers are initialized with 0. In the cleanup series since we are using _gpio_rmw(reg, 0, 1), instead of __raw_writel(), we are just reading and writing the same values to ctrl and debounce_en. This is not an issue for debounce_en register because it has 0x0 as the default value. But in the case of ctrl register the default value is 0x2 (GATINGRATIO = 0x1) so that we end up writing 0x2 instead of intended 0 value. Therefore changing back to __raw_writel() as this is sufficient for this case besides simpler to understand. Also, change irqstatus initalization logic that avoids comparison with bool, besides making it fit in a single line. Cc: stable@vger.kernel.org Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Reported-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
- 08 May, 2012 2 commits
-
-
Mika Westerberg authored
irq_domain already provides a facility to translate from hardware IRQ numbers to Linux IRQ numbers so use that instead of open-coding the logic in the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
-
Grant Likely authored
Linux 3.4-rc6
-
- 06 May, 2012 5 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes form Peter Anvin * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND arch/x86/platform/geode/net5501.c: change active_low to 0 for LED driver x86, relocs: Remove an unused variable asm-generic: Use __BITS_PER_LONG in statfs.h x86/amd: Re-enable CPU topology extensions in case BIOS has disabled it
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfsLinus Torvalds authored
Pull btrfs fixes from Chris Mason: "The big ones here are a memory leak we introduced in rc1, and a scheduling while atomic if the transid on disk doesn't match the transid we expected. This happens for corrupt blocks, or out of date disks. It also fixes up the ioctl definition for our ioctl to resolve logical inode numbers. The __u32 was a merging error and doesn't match what we ship in the progs." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: avoid sleeping in verify_parent_transid while atomic Btrfs: fix crash in scrub repair code when device is missing btrfs: Fix mismatching struct members in ioctl.h Btrfs: fix page leak when allocing extent buffers Btrfs: Add properly locking around add_root_to_dirty_list
-
Al Viro authored
Setting TIF_IA32 in load_aout_binary() used to be enough; these days TASK_SIZE is controlled by TIF_ADDR32 and that one doesn't get set there. Switch to use of set_personality_ia32()... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Chris Mason authored
verify_parent_transid needs to lock the extent range to make sure no IO is underway, and so it can safely clear the uptodate bits if our checks fail. But, a few callers are using it with spinlocks held. Most of the time, the generation numbers are going to match, and we don't want to switch to a blocking lock just for the error case. This adds an atomic flag to verify_parent_transid, and changes it to return EAGAIN if it needs to block to properly verifiy things. Signed-off-by: Chris Mason <chris.mason@oracle.com>
-
- 05 May, 2012 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alphaLinus Torvalds authored
Pull alpha fixes from Matt Turner: "My alpha tree is back up (after taking quite some time to get my GPG key signed). It contains just some simple fixes." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha: alpha: silence 'const' warning in sys_marvel.c alpha: include module.h to fix modpost on Tsunami alpha: properly define get/set_rtc_time on Marvel/SMP alpha: VGA_HOSE depends on VGA_CONSOLE
-
Jiri Slaby authored
The test in pdc_console_tty_close '!tty->count' was always wrong because tty->count is decremented after tty->ops->close is called and thus can never be zero. Hence the 'then' branch was never executed and the timer never deleted. This did not matter until commit 5dd5bc40 ("TTY: pdc_cons, use tty_port"). There we needed to set TTY in tty_port to NULL, but this never happened due to the bug above. So change the test to really trigger at the last close by changing the condition to 'tty->count == 1'. Well, the driver should not touch tty->count at all. It should use tty_port->count and count open count there itself. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-and-tested-by: Mikulas Patocka <mpatocka@redhat.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Helge Deller <deller@gmx.de> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds authored
Pull sound sound fixes from Takashi Iwai: "As good as nothing exciting here; just a few trivial fixes for various ASoC stuff." * tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: omap-pcm: Free dma buffers in case of error. ASoC: s3c2412-i2s: Fix dai registration ASoC: wm8350: Don't use locally allocated codec struct ASoC: tlv312aic23: unbreak resume ASoC: bf5xx-ssm2602: Set DAI format ASoC: core: check of_property_count_strings failure ASoC: dt: sgtl5000.txt: Add description for 'reg' field ASoC: wm_hubs: Make sure we don't disable differential line outputs
-
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linuxLinus Torvalds authored
Pull an ACPI patch from Len Brown: "It fixes a D3 issue new in 3.4-rc1." By Lin Ming via Len Brown: * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: ACPI: Fix D3hot v D3cold confusion
-
Sasha Levin authored
Currently, we'll try mounting any device who's major device number is UNNAMED_MAJOR as NFS root. This would happen for non-NFS devices as well (such as 9p devices) but it wouldn't cause any issues since mounting the device as NFS would fail quickly and the code proceeded to doing the proper mount: [ 101.522716] VFS: Unable to mount root fs via NFS, trying floppy. [ 101.534499] VFS: Mounted root (9p filesystem) on device 0:18. Commit 6829a048102a ("NFS: Retry mounting NFSROOT") introduced retries when mounting NFS root, which means that now we don't immediately fail and instead it takes an additional 90+ seconds until we stop retrying, which has revealed the issue this patch fixes. This meant that it would take an additional 90 seconds to boot when we're not using a device type which gets detected in order before NFS. This patch modifies the NFS type check to require device type to be 'Root_NFS' instead of requiring the device to have an UNNAMED_MAJOR major. This makes boot process cleaner since we now won't go through the NFS mounting code at all when the device isn't an NFS root ("/dev/nfs"). Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Takashi Iwai authored
-