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>
      4018294b
  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
      9e368fa0
      
       ("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
       	pnp_register_driver(&ipmi_pnp_driver);
       #endif
      
      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>
      27d0567a
  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
      protection.
      
      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.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12454
      
      
      
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  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>
      1855256c
  19. 19 Sep, 2007 1 commit