1. 13 6月, 2016 1 次提交
  2. 08 6月, 2016 7 次提交
  3. 30 5月, 2016 5 次提交
  4. 28 5月, 2016 1 次提交
    • A
      remove lots of IS_ERR_VALUE abuses · 287980e4
      Arnd Bergmann 提交于
      Most users of IS_ERR_VALUE() in the kernel are wrong, as they
      pass an 'int' into a function that takes an 'unsigned long'
      argument. This happens to work because the type is sign-extended
      on 64-bit architectures before it gets converted into an
      unsigned type.
      
      However, anything that passes an 'unsigned short' or 'unsigned int'
      argument into IS_ERR_VALUE() is guaranteed to be broken, as are
      8-bit integers and types that are wider than 'unsigned long'.
      
      Andrzej Hajda has already fixed a lot of the worst abusers that
      were causing actual bugs, but it would be nice to prevent any
      users that are not passing 'unsigned long' arguments.
      
      This patch changes all users of IS_ERR_VALUE() that I could find
      on 32-bit ARM randconfig builds and x86 allmodconfig. For the
      moment, this doesn't change the definition of IS_ERR_VALUE()
      because there are probably still architecture specific users
      elsewhere.
      
      Almost all the warnings I got are for files that are better off
      using 'if (err)' or 'if (err < 0)'.
      The only legitimate user I could find that we get a warning for
      is the (32-bit only) freescale fman driver, so I did not remove
      the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
      For 9pfs, I just worked around one user whose calling conventions
      are so obscure that I did not dare change the behavior.
      
      I was using this definition for testing:
      
       #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
             unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
      
      which ends up making all 16-bit or wider types work correctly with
      the most plausible interpretation of what IS_ERR_VALUE() was supposed
      to return according to its users, but also causes a compile-time
      warning for any users that do not pass an 'unsigned long' argument.
      
      I suggested this approach earlier this year, but back then we ended
      up deciding to just fix the users that are obviously broken. After
      the initial warning that caused me to get involved in the discussion
      (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
      asked me to send the whole thing again.
      
      [ Updated the 9p parts as per Al Viro  - Linus ]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: https://lkml.org/lkml/2016/1/7/363
      Link: https://lkml.org/lkml/2016/5/27/486
      Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      287980e4
  5. 11 5月, 2016 5 次提交
    • P
      gpio: zevio: make it explicitly non-modular · a90295b4
      Paul Gortmaker 提交于
      The Kconfig currently controlling compilation of this code is:
      
      drivers/gpio/Kconfig:config GPIO_ZEVIO
      drivers/gpio/Kconfig:   bool "LSI ZEVIO SoC memory mapped GPIOs"
      
      ...meaning that it currently is not being built as a module by anyone.
      
      Lets remove the modular code that is essentially orphaned, so that
      when reading the driver there is no doubt it is builtin-only.
      
      We explicitly disallow a driver unbind, since that doesn't have a
      sensible use case anyway, and it allows us to drop the ".remove"
      code for non-modular drivers.
      
      Since module_platform_driver() uses the same init level priority as
      builtin_platform_driver() the init ordering remains unchanged with
      this commit.
      
      Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
      
      We also delete the MODULE_LICENSE tag etc. since all that information
      is already contained at the top of the file in the comments.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Fabian Vogt <fabian@ritter-vogt.de>
      Cc: linux-gpio@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      a90295b4
    • P
      gpio: timberdale: make it explicitly non-modular · 52ad9053
      Paul Gortmaker 提交于
      The Kconfig currently controlling compilation of this code is:
      
      drivers/gpio/Kconfig:config GPIO_TIMBERDALE
      drivers/gpio/Kconfig:   bool "Support for timberdale GPIO IP"
      
      ...meaning that it currently is not being built as a module by anyone.
      
      Lets remove the modular code that is essentially orphaned, so that
      when reading the driver there is no doubt it is builtin-only.
      
      We explicitly disallow a driver unbind, since that doesn't have a
      sensible use case anyway, and it allows us to drop the ".remove"
      code for non-modular drivers.
      
      Since module_platform_driver() uses the same init level priority as
      builtin_platform_driver() the init ordering remains unchanged with
      this commit.
      
      We also delete the MODULE_LICENSE tag etc. since all that information
      was (or is now) contained at the top of the file in the comments.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: linux-gpio@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      52ad9053
    • P
      gpio: stmpe: make it explicitly non-modular · 3b52bb96
      Paul Gortmaker 提交于
      The Kconfig currently controlling compilation of this code is:
      
      drivers/gpio/Kconfig:config GPIO_STMPE
      drivers/gpio/Kconfig:   bool "STMPE GPIOs"
      
      ...meaning that it currently is not being built as a module by anyone.
      
      Lets remove the modular code that is essentially orphaned, so that
      when reading the driver there is no doubt it is builtin-only.
      
      We explicitly disallow a driver unbind, since that doesn't have a
      sensible use case anyway, and it allows us to drop the ".remove"
      code for non-modular drivers.
      
      Curiously, this driver was using subsys_initcall since day one, so
      we don't have the "normal" module_init replacement in this change
      like we've done in other similar driver updates.
      
      We also delete the MODULE_LICENSE tag etc. since all that information
      is already contained at the top of the file in the comments.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Rabin Vincent <rabin.vincent@stericsson.com>
      Cc: linux-gpio@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      3b52bb96
    • P
      gpio: sodaville: make it explicitly non-modular · 6a5ead91
      Paul Gortmaker 提交于
      The Kconfig currently controlling compilation of this code is:
      
      drivers/gpio/Kconfig:config GPIO_SODAVILLE
      drivers/gpio/Kconfig:   bool "Intel Sodaville GPIO support"
      
      ...meaning that it currently is not being built as a module by anyone.
      
      Lets remove the modular code that is essentially orphaned, so that
      when reading the driver there is no doubt it is builtin-only.
      
      We explicitly disallow a driver unbind, since that doesn't have a
      sensible use case anyway, and it allows us to drop the ".remove"
      code for non-modular drivers.
      
      Since module_pci_driver() uses the same init level as the
      builtin_pci_driver() does, there is no init ordering change
      caused by this commit.
      
      We don't replace module.h with init.h since the file already has that.
      
      We also delete the MODULE_LICENSE tag etc. since all that information
      was (or is now) contained at the top of the file in the comments.
      
      Cc: Hans J. Koch <hjk@linutronix.de>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: linux-gpio@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      6a5ead91
    • D
      gpio: dwapb: Add ACPI device ID for DWAPB GPIO controller on X-Gene platforms · 1b0d5287
      Duc Dang 提交于
      This patch enables DWAPB GPIO controller support on X-Gene
      platforms in ACPI boot mode.
      Signed-off-by: NDuc Dang <dhdang@apm.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      1b0d5287
  6. 10 5月, 2016 1 次提交
    • L
      gpio: of: make it possible to name GPIO lines · fd9c5531
      Linus Walleij 提交于
      Make it possible to name the producer side of a GPIO line using
      a "gpio-line-names" property array, modeled on the
      "clock-output-names" property from the clock bindings.
      
      This naming is especially useful for:
      
      - Debugging: lines are named after function, not just opaque
        offset numbers.
      
      - Exploration: systems where some or all GPIO lines are available
        to end users, such as prototyping, one-off's "makerspace usecases"
        users are helped by the names of the GPIO lines when tinkering.
        This usecase has been surfacing recently.
      
      The gpio-line-names attribute is completely optional.
      
      Example output from lsgpio on a patched Snowball tree:
      
      GPIO chip: gpiochip6, "8000e180.gpio", 32 GPIO lines
              line  0: unnamed unused
              line  1: "AP_GPIO161" "extkb3" [kernel]
              line  2: "AP_GPIO162" "extkb4" [kernel]
              line  3: "ACCELEROMETER_INT1_RDY" unused [kernel]
              line  4: "ACCELEROMETER_INT2" unused
              line  5: "MAG_DRDY" unused [kernel]
              line  6: "GYRO_DRDY" unused [kernel]
              line  7: "RSTn_MLC" unused
              line  8: "RSTn_SLC" unused
              line  9: "GYRO_INT" unused
              line 10: "UART_WAKE" unused
              line 11: "GBF_RESET" unused
              line 12: unnamed unused
      
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Amit Kucheria <amit.kucheria@linaro.org>
      Cc: David Mandala <david.mandala@linaro.org>
      Cc: Lee Campbell <leecam@google.com>
      Cc: devicetree@vger.kernel.org
      Acked-by: NRob Herring <robh@kernel.org>
      Reviewed-by: NMichael Welling <mwelling@ieee.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      fd9c5531
  7. 03 5月, 2016 4 次提交
  8. 02 5月, 2016 1 次提交
  9. 01 5月, 2016 2 次提交
  10. 30 4月, 2016 3 次提交
    • V
      gpiolib-acpi: Duplicate con_id string when adding it to the crs lookup list · 7df89e92
      Ville Syrjälä 提交于
      Calling gpiod_get() from a module and then unloading the module leads to an
      oops due to acpi_can_fallback_to_crs() storing the pointer to the passed
      'con_id' string onto acpi_crs_lookup_list. The next guy to come along will then
      try to access the string but the memory may now be gone with the module.
      Make a copy of the passed string instead, and store the copy on the list.
      
      BUG: unable to handle kernel paging request at ffffffffa03e7855
      IP: [<ffffffff81338322>] strcmp+0x12/0x30
      PGD 2a07067 PUD 2a08063 PMD 74720067 PTE 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: i915(+) drm_kms_helper drm intel_gtt snd_hda_codec snd_hda_core i2c_algo_bit syscopya
      rea sysfillrect sysimgblt fb_sys_fops agpgart snd_soc_sst_bytcr_rt5640 coretemp hwmon intel_rapl intel_soc_dts_thermal
      punit_atom_debug snd_soc_rt5640 snd_soc_rl6231 serio snd_intel_sst_acpi snd_intel_sst_core video snd_soc_sst_mfld_platf
      orm snd_soc_sst_match backlight int3402_thermal processor_thermal_device int3403_thermal int3400_thermal acpi_thermal_r
      el snd_soc_core intel_soc_dts_iosf int340x_thermal_zone snd_compress i2c_hid hid snd_pcm snd_timer snd soundcore evdev
      sch_fq_codel efivarfs ipv6 autofs4 [last unloaded: drm]
      CPU: 2 PID: 3064 Comm: modprobe Tainted: G     U  W       4.6.0-rc3-ffrd-ipvr+ #302
      Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8
      _X64_R_2014_13_1_00 03/24/2014
      task: ffff8800701cd200 ti: ffff880070034000 task.ti: ffff880070034000
      RIP: 0010:[<ffffffff81338322>]  [<ffffffff81338322>] strcmp+0x12/0x30
      RSP: 0000:ffff880070037748  EFLAGS: 00010286
      RAX: 0000000080000000 RBX: ffff88007a342800 RCX: 0000000000000006
      RDX: 0000000000000006 RSI: ffffffffa054f856 RDI: ffffffffa03e7856
      RBP: ffff880070037748 R08: 0000000000000000 R09: 0000000000000001
      R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa054f855
      R13: ffff88007281cae0 R14: 0000000000000010 R15: ffffffffffffffea
      FS:  00007faa51447700(0000) GS:ffff880079300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffa03e7855 CR3: 0000000041eba000 CR4: 00000000001006e0
      Stack:
       ffff880070037770 ffffffff8136ad28 ffffffffa054f855 0000000000000000
       ffff88007a0a2098 ffff8800700377e8 ffffffff8136852e ffff88007a342800
       00000007700377a0 ffff8800700377a0 ffffffff81412442 70672d6c656e6170
      Call Trace:
       [<ffffffff8136ad28>] acpi_can_fallback_to_crs+0x88/0x100
       [<ffffffff8136852e>] gpiod_get_index+0x25e/0x310
       [<ffffffff81412442>] ? mipi_dsi_attach+0x22/0x30
       [<ffffffff813685f2>] gpiod_get+0x12/0x20
       [<ffffffffa04fcf41>] intel_dsi_init+0x421/0x480 [i915]
       [<ffffffffa04d3783>] intel_modeset_init+0x853/0x16b0 [i915]
       [<ffffffffa0504864>] ? intel_setup_gmbus+0x214/0x260 [i915]
       [<ffffffffa0510158>] i915_driver_load+0xdc8/0x19b0 [i915]
       [<ffffffff8160fb53>] ? _raw_spin_unlock_irqrestore+0x43/0x70
       [<ffffffffa026b13b>] drm_dev_register+0xab/0xc0 [drm]
       [<ffffffffa026d7b3>] drm_get_pci_dev+0x93/0x1f0 [drm]
       [<ffffffff8160fb53>] ? _raw_spin_unlock_irqrestore+0x43/0x70
       [<ffffffffa043f1f4>] i915_pci_probe+0x34/0x50 [i915]
       [<ffffffff81379751>] pci_device_probe+0x91/0x100
       [<ffffffff8141a75a>] driver_probe_device+0x20a/0x2d0
       [<ffffffff8141a8be>] __driver_attach+0x9e/0xb0
       [<ffffffff8141a820>] ? driver_probe_device+0x2d0/0x2d0
       [<ffffffff81418439>] bus_for_each_dev+0x69/0xa0
       [<ffffffff8141a04e>] driver_attach+0x1e/0x20
       [<ffffffff81419c20>] bus_add_driver+0x1c0/0x240
       [<ffffffff8141b6d0>] driver_register+0x60/0xe0
       [<ffffffff81377d20>] __pci_register_driver+0x60/0x70
       [<ffffffffa026d9f4>] drm_pci_init+0xe4/0x110 [drm]
       [<ffffffff810ce04e>] ? trace_hardirqs_on+0xe/0x10
       [<ffffffffa02f1000>] ? 0xffffffffa02f1000
       [<ffffffffa02f1094>] i915_init+0x94/0x9b [i915]
       [<ffffffff810003bb>] do_one_initcall+0x8b/0x1c0
       [<ffffffff810eb616>] ? rcu_read_lock_sched_held+0x86/0x90
       [<ffffffff811de6d6>] ? kmem_cache_alloc_trace+0x1f6/0x270
       [<ffffffff81183826>] do_init_module+0x60/0x1dc
       [<ffffffff81115a8d>] load_module+0x1d0d/0x2390
       [<ffffffff811120b0>] ? __symbol_put+0x70/0x70
       [<ffffffff811f41b2>] ? kernel_read_file+0x92/0x120
       [<ffffffff811162f4>] SYSC_finit_module+0xa4/0xb0
       [<ffffffff8111631e>] SyS_finit_module+0xe/0x10
       [<ffffffff81001ff3>] do_syscall_64+0x63/0x350
       [<ffffffff816103da>] entry_SYSCALL64_slow_path+0x25/0x25
      Code: f7 48 8d 76 01 48 8d 52 01 0f b6 4e ff 84 c9 88 4a ff 75 ed 5d c3 0f 1f 00 55 48 89 e5 eb 04 84 c0
       74 18 48 8d 7f 01 48 8d 76 01 <0f> b6 47 ff 3a 46 ff 74 eb 19 c0 83 c8 01 5d c3 31 c0 5d c3 66
      RIP  [<ffffffff81338322>] strcmp+0x12/0x30
       RSP <ffff880070037748>
      CR2: ffffffffa03e7855
      
      v2: Make the copied con_id const
      
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: stable@vger.kernel.org
      Fixes: 10cf4899 ("gpiolib: tighten up ACPI legacy gpio lookups")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      7df89e92
    • L
      gpio: tegra: Implement gpio_get_direction callback · f002d07c
      Laxman Dewangan 提交于
      Implement gpio_get_direction() callback for Tegra GPIO.
      The direction is only valid if the pin is configured as
      GPIO. If pin is not configured in GPIO mode then this
      function return error.
      Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      f002d07c
    • L
      gpio: set up initial state from .get_direction() · 72d32000
      Linus Walleij 提交于
      If the gpiochip supports the .get_direction() callback, then
      the initial state of the descriptor flags should be set up
      as output accordingly. Also put in comments explaining what is
      going on.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      72d32000
  11. 29 4月, 2016 10 次提交