1. 07 3月, 2016 2 次提交
  2. 06 2月, 2016 8 次提交
  3. 07 1月, 2016 1 次提交
  4. 31 12月, 2015 1 次提交
    • R
      bcma: use module_init for the main part of bus initialization · 0510931e
      Rafał Miłecki 提交于
      So far we were using fs_initcall. It was (and still is) needed because
      struct bus_type has to be registered early. However main bus
      initialization has to happen later as it requires SPROM which depends on
      NVRAM which depends on mtd.
      Solve it by using fs_initcall only for bus_register call and module_init
      for the rest. It affects bcma only when built-in obviously.
      
      This was tested with BCM4706 and BCM5357C0 (BCM47XX), BCM4708A0
      (ARCH_BCM_5301X) and BCM43225 (PCIe card with bcma as module).
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      0510931e
  5. 19 11月, 2015 1 次提交
    • L
      gpio: change member .dev to .parent · 58383c78
      Linus Walleij 提交于
      The name .dev in a struct is normally reserved for a struct device
      that is let us say a superclass to the thing described by the struct.
      struct gpio_chip stands out by confusingly using a struct device *dev
      to point to the parent device (such as a platform_device) that
      represents the hardware. As we want to give gpio_chip:s real devices,
      this is not working. We need to rename this member to parent.
      
      This was done by two coccinelle scripts, I guess it is possible to
      combine them into one, but I don't know such stuff. They look like
      this:
      
      @@
      struct gpio_chip *var;
      @@
      -var->dev
      +var->parent
      
      and:
      
      @@
      struct gpio_chip var;
      @@
      -var.dev
      +var.parent
      
      and:
      
      @@
      struct bgpio_chip *var;
      @@
      -var->gc.dev
      +var->gc.parent
      
      Plus a few instances of bgpio that I couldn't figure out how
      to teach Coccinelle to rewrite.
      
      This patch hits all over the place, but I *strongly* prefer this
      solution to any piecemal approaches that just exercise patch
      mechanics all over the place. It mainly hits drivers/gpio and
      drivers/pinctrl which is my own backyard anyway.
      
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Alek Du <alek.du@intel.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Acked-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
      Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      58383c78
  6. 29 9月, 2015 1 次提交
  7. 18 8月, 2015 1 次提交
  8. 11 8月, 2015 1 次提交
    • H
      bcma: fix access to host_pdev for PCIe devices · 53cd2fdb
      Hauke Mehrtens 提交于
      bus->host_pdev is part of a union so bus->host_pdev != NULL is probably
      also true for PCIe devices, because there it accesses bus->host_pci. If
      we access the dev member at the offset defined in struct
      platform_device in struct pci_dev instead we probably get something
      else.
      
      This patch adds a new function which returns the host dev struct and
      NULL if we do not have a host dev. When this gets registered on MIPS
      brcm47xx we do not have a host dev in some situations.
      This function could also be used in other places.
      
      This problem was introduced in this commit:
      commit cae761b5
      Author: Rafa? Mi?ecki <zajec5@gmail.com>
      Date:   Sun Jun 28 17:17:13 2015 +0200
      
          bcma: populate bus DT subnodes as platform_device-s
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      53cd2fdb
  9. 26 7月, 2015 1 次提交
  10. 21 7月, 2015 1 次提交
  11. 08 6月, 2015 1 次提交
  12. 09 5月, 2015 2 次提交
  13. 01 4月, 2015 1 次提交
  14. 20 3月, 2015 1 次提交
  15. 13 3月, 2015 3 次提交
  16. 05 3月, 2015 3 次提交
  17. 03 3月, 2015 2 次提交
  18. 02 3月, 2015 4 次提交
  19. 29 1月, 2015 5 次提交