1. 25 3月, 2009 1 次提交
    • M
      Driver core: implement uevent suppress in kobject · f67f129e
      Ming Lei 提交于
      This patch implements uevent suppress in kobject and removes it
      from struct device, based on the following ideas:
      
      1,Uevent sending should be one attribute of kobject, so suppressing it
      in kobject layer is more natural than in device layer. By this way,
      we can do it for other objects embedded with kobject.
      
      2,It may save several bytes for each instance of struct device.(On my
      omap3(32bit ARM) based box, can save 8bytes per device object)
      
      This patch also introduces dev_set|get_uevent_suppress() helpers to
      set and query uevent_suppress attribute in case to help kobject
      as private part of struct device in future.
      
      [This version is against the latest driver-core patch set of Greg,please
      ignore the last version.]
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f67f129e
  2. 16 3月, 2009 5 次提交
  3. 23 2月, 2009 1 次提交
  4. 22 2月, 2009 3 次提交
  5. 20 2月, 2009 1 次提交
  6. 09 2月, 2009 2 次提交
  7. 07 2月, 2009 7 次提交
  8. 06 2月, 2009 1 次提交
    • P
      netlink: change return-value logic of netlink_broadcast() · ff491a73
      Pablo Neira Ayuso 提交于
      Currently, netlink_broadcast() reports errors to the caller if no
      messages at all were delivered:
      
      1) If, at least, one message has been delivered correctly, returns 0.
      2) Otherwise, if no messages at all were delivered due to skb_clone()
         failure, return -ENOBUFS.
      3) Otherwise, if there are no listeners, return -ESRCH.
      
      With this patch, the caller knows if the delivery of any of the
      messages to the listeners have failed:
      
      1) If it fails to deliver any message (for whatever reason), return
         -ENOBUFS.
      2) Otherwise, if all messages were delivered OK, returns 0.
      3) Otherwise, if no listeners, return -ESRCH.
      
      In the current ctnetlink code and in Netfilter in general, we can add
      reliable logging and connection tracking event delivery by dropping the
      packets whose events were not successfully delivered over Netlink. Of
      course, this option would be settable via /proc as this approach reduces
      performance (in terms of filtered connections per seconds by a stateful
      firewall) but providing reliable logging and event delivery (for
      conntrackd) in return.
      
      This patch also changes some clients of netlink_broadcast() that
      may report ENOBUFS errors via printk. This error handling is not
      of any help. Instead, the userspace daemons that are listening to
      those netlink messages should resync themselves with the kernel-side
      if they hit ENOBUFS.
      
      BTW, netlink_broadcast() clients include those that call
      cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they
      internally call netlink_broadcast() and return its error value.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff491a73
  9. 04 2月, 2009 3 次提交
  10. 03 2月, 2009 2 次提交
  11. 29 1月, 2009 2 次提交
    • L
      ACPI: remove BM_RLD access from idle entry path · 31878dd8
      Len Brown 提交于
      It is true that BM_RLD needs to be set to enable
      bus master activity to wake an older chipset (eg PIIX4) from C3.
      
      This is contrary to the erroneous wording the ACPI 2.0, 3.0
      specifications that suggests that BM_RLD is an indicator
      rather than a control bit.
      
      ACPI 1.0's correct wording should be restored in ACPI 4.0:
      http://www.acpica.org/bugzilla/show_bug.cgi?id=689
      
      But the kernel should not have to clear BM_RLD
      when entering a non C3-type state just to set
      it again when entering a C3-type C-state.
      
      We should be able to set BM_RLD at boot time
      and leave it alone -- removing the overhead of
      accessing this IO register from the idle entry path.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      31878dd8
    • L
      ACPI: remove locking from PM1x_STS register reads · a2b7b01c
      Len Brown 提交于
      PM1a_STS and PM1b_STS are twins that get OR'd together
      on reads, and all writes are repeated to both.
      
      The fields in PM1x_STS are single bits only,
      there are no multi-bit fields.
      
      So it is not necessary to lock PM1x_STS reads against
      writes because it is impossible to read an intermediate
      value of a single bit.  It will either be 0 or 1,
      even if a write is in progress during the read.
      Reads are asynchronous to writes no matter if a lock
      is used or not.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      a2b7b01c
  12. 18 1月, 2009 1 次提交
  13. 17 1月, 2009 5 次提交
  14. 09 1月, 2009 6 次提交