1. 27 May, 2010 10 commits
  2. 22 May, 2010 1 commit
    • Grant Likely's avatar
      of: Remove duplicate fields from of_platform_driver · 4018294b
      Grant Likely authored
      .name, .match_table and .owner are duplicated in both of_platform_driver
      and device_driver.  This patch is a removes the extra copies from struct
      of_platform_driver and converts all users to the device_driver members.
      This patch is a pretty mechanical change.  The usage model doesn't change
      and if any drivers have been missed, or if anything has been fixed up
      incorrectly, then it will fail with a compile time error, and the fixup
      will be trivial.  This patch looks big and scary because it touches so
      many files, but it should be pretty safe.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Acked-by: default avatarSean MacLennan <smaclennan@pikatech.com>
  3. 18 May, 2010 1 commit
  4. 12 Mar, 2010 2 commits
  5. 29 Dec, 2009 1 commit
    • Ingo Molnar's avatar
      ACPI: fix ACPI=n allmodconfig build · 27d0567a
      Ingo Molnar authored
      Today's -tip failed to build because commit
       ("ipmi: add PNP discovery (ACPI
      namespace via PNPACPI)") from today's upstream kernel causes the following
      build failure on x86, for CONFIG_ACPI=n && CONFIG_IPMI_SI=y:
       drivers/char/ipmi/ipmi_si_intf.c:3208: error: 'ipmi_pnp_driver' undeclared (first use in this function)
       drivers/char/ipmi/ipmi_si_intf.c:3208: error: (Each undeclared identifier is reported only once
       drivers/char/ipmi/ipmi_si_intf.c:3208: error: for each function it appears in.)
       drivers/char/ipmi/ipmi_si_intf.c:3334: error: 'ipmi_pnp_driver' undeclared (first use in this function)
      The reason is that the ipmi_pnp_driver depends on ACPI facilities and is only
      made available under ACPI - while the registration and unregistration is made
      dependent on CONFIG_PNP:
       #ifdef CONFIG_PNP
      The solution is to only register this driver under ACPI. (Also, the CONFIG_PNP
      dependency is not needed because pnp_register_driver() is stubbed out in the
      !CONFIG_PNP case.)
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
  6. 15 Dec, 2009 3 commits
  7. 15 Jun, 2009 1 commit
  8. 21 Apr, 2009 2 commits
  9. 30 Mar, 2009 1 commit
    • Alexey Dobriyan's avatar
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan authored
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      ->read_proc/->write_proc were just fixed to not require ->owner for
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      Removing ->owner will also make PDE smaller.
      So, let's nuke it.
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
  10. 12 Nov, 2008 1 commit
  11. 23 Sep, 2008 1 commit
  12. 20 Aug, 2008 1 commit
  13. 29 Jul, 2008 1 commit
  14. 14 May, 2008 1 commit
  15. 29 Apr, 2008 7 commits
  16. 18 Oct, 2007 3 commits
  17. 14 Oct, 2007 1 commit
  18. 09 Oct, 2007 1 commit
    • Jeff Garzik's avatar
      drivers/firmware: const-ify DMI API and internals · 1855256c
      Jeff Garzik authored
      Three main sets of changes:
      1) dmi_get_system_info() return value should have been marked const,
         since callers should not be changing that data.
      2) const-ify DMI internals, since DMI firmware tables should,
         whenever possible, be marked const to ensure we never ever write to
         that data area.
      3) const-ify DMI API, to enable marking tables const where possible
         in low-level drivers.
      And if we're really lucky, this might enable some additional
      optimizations on the part of the compiler.
      The bulk of the changes are #2 and #3, which are interrelated.  #1 could
      have been a separate patch, but it was so small compared to the others,
      it was easier to roll it into this changeset.
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
  19. 19 Sep, 2007 1 commit