Skip to content

L
linux
Switch branch/tag
  1. 18 May, 2010 1 commit
  3. 29 Apr, 2010 5 commits
    • Grant Likely's avatar
      i2c/of: Allow device node to be passed via i2c_board_info · d12d42f7
      Grant Likely authored 
      The struct device_node *of_node pointer is moving out of dev->archdata
and into the struct device proper.  of_i2c.c needs to set the of_node
pointer before the device is registered.  Since the i2c subsystem
doesn't allow 2 stage allocation and registration of i2c devices, the
of_node pointer needs to be passed via the i2c_board_info structure
so that it is set prior to registration.

This patch adds of_node to struct i2c_board_info (conditional on
CONFIG_OF), sets of_node in i2c_new_device(), and modifies of_i2c.c
to use the new parameter.  The calling of dev_archdata_set_node()
from of_i2c will be removed in a subsequent patch when of_node is
removed from archdata and all users are converted over.
Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      d12d42f7
    • Grant Likely's avatar
      driver-core: Add device node pointer to struct device · d706c1b0
      Grant Likely authored 
      Currently, platforms using CONFIG_OF add a 'struct device_node *of_node'
to dev->archdata.  However, with CONFIG_OF becoming generic for all
architectures, it makes sense for commonality to move it out of archdata
and into struct device proper.

This patch adds a struct device_node *of_node member to struct device
and updates all locations which currently write the device_node pointer
into archdata to also update dev->of_node.  Subsequent patches will
modify callers to use the archdata location and ultimately remove
the archdata member entirely.
Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
CC: Michal Simek <monstr@monstr.eu>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: "David S. Miller" <davem@davemloft.net>
CC: Stephen Rothwell <sfr@canb.auug.org.au>
CC: Jeremy Kerr <jeremy.kerr@canonical.com>
CC: microblaze-uclinux@itee.uq.edu.au
CC: linux-kernel@vger.kernel.org
CC: linuxppc-dev@ozlabs.org
CC: sparclinux@vger.kernel.org
      d706c1b0
    • Grant Likely's avatar
      of: protect contents of of_platform.h and of_device.h · efb2e014
      Grant Likely authored 
      Only process contents of of_platform.h and of_device.h if
CONFIG_OF_DEVICE is set.
Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      efb2e014
    • Grant Likely's avatar
      of/flattree: Make unflatten_device_tree() safe to call from any arch · 8bfe9b5c
      Grant Likely authored 
      This patch makes unflatten_device_tree() safe to call from any arch
setup code with the following changes:
- Make sure initial_boot_params actually points to a device tree blob
  before unflattening
- Make sure the initial_boot_params->magic field is correct
- If CONFIG_OF_FLATTREE is not set, then make unflatten_device_tree()
  an empty static inline function.

This patch also adds some additional debug output to the top of
unflatten_device_tree().
Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      8bfe9b5c
    • Grant Likely's avatar
      of/flattree: make of_fdt.h safe to unconditionally include. · cf32eb89
      Grant Likely authored 
      If CONFIG_OF_FLATTREE is not set, then don't process the body of
linux/of_fdt.h
Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      cf32eb89
  5. 19 Apr, 2010 24 commits
  7. 18 Apr, 2010 1 commit
  9. 17 Apr, 2010 3 commits
  11. 16 Apr, 2010 6 commits
    • Daniel Lezcano's avatar
      packet : remove init_net restriction · 1c4f0197
      Daniel Lezcano authored 
      The af_packet protocol is used by Perl to do ioctls as reported by
Stephane Riviere:

"Net::RawIP relies on SIOCGIFADDR et SIOCGIFHWADDR to get the IP and MAC
addresses of the network interface."

But in a new network namespace these ioctl fail because it is disabled for
a namespace different from the init_net_ns.

These two lines should not be there as af_inet and af_packet are
namespace aware since a long time now. I suppose we forget to remove these
lines because we sent the af_packet first, before af_inet was supported.
Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@free.fr>
Reported-by: default avatarStephane Riviere <stephane.riviere@regis-dgac.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c4f0197
    • Krzysztof Halasa's avatar
      WAN: flush tx_queue in hdlc_ppp to prevent panic on rmmod hw_driver. · 31f634a6
      Krzysztof Halasa authored 
      tx_queue is used as a temporary queue when not allowed to queue skb
directly to the hw device driver (which may sleep). Most paths flush
it before returning, but ppp_start() currently cannot. Make sure we
don't leave skbs pointing to a non-existent device.

Thanks to Michael Barkowski for reporting this problem.
Signed-off-by: default avatarKrzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31f634a6
    • Len Brown's avatar
      Merge branch 'bugzilla-15749' into release · bc396692
      Len Brown authored
      bc396692
    • Alexey Starikovskiy's avatar
      ACPI: EC: Limit burst to 64 bits · 2060c445
      Alexey Starikovskiy authored 
      access_bit_width field is u8 in ACPICA, thus 256 value written to it
becomes 0, causing divide by zero later.

Proper fix would be to remove access_bit_width at all, just because
we already have access_byte_width, which is access_bit_width / 8.
Limit access width to 64 bit for now.

https://bugzilla.kernel.org/show_bug.cgi?id=15749
fixes regression caused by the fix for:
https://bugzilla.kernel.org/show_bug.cgi?id=14667Signed-off-by: default avatarAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      2060c445
    • Dave Chinner's avatar
      xfs: don't warn on EAGAIN in inode reclaim · f1d486a3
      Dave Chinner authored 
      Any inode reclaim flush that returns EAGAIN will result in the inode
reclaim being attempted again later. There is no need to issue a
warning into the logs about this situation.
Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
Reviewed-by: default avatarAlex Elder <aelder@sgi.com>
Signed-off-by: default avatarAlex Elder <aelder@sgi.com>
      f1d486a3
    • Dave Chinner's avatar
      xfs: ensure that sync updates the log tail correctly · b6f8dd49
      Dave Chinner authored 
      Updates to the VFS layer removed an extra ->sync_fs call into the
filesystem during the sync process (from the quota code).
Unfortunately the sync code was unknowingly relying on this call to
make sure metadata buffers were flushed via a xfs_buftarg_flush()
call to move the tail of the log forward in memory before the final
transactions of the sync process were issued.

As a result, the old code would write a very recent log tail value
to the log by the end of the sync process, and so a subsequent crash
would leave nothing for log recovery to do. Hence in qa test 182,
log recovery only replayed a small handle for inode fsync
transactions in this case.

However, with the removal of the extra ->sync_fs call, the log tail
was now not moved forward with the inode fsync transactions near the
end of the sync procese the first (and only) buftarg flush occurred
after these transactions went to disk. The result is that log
recovery now sees a large number of transactions for metadata that
is already on disk.

This usually isn't a problem, but when the transactions include
inode chunk allocation, the inode create transactions and all
subsequent changes are replayed as we cannt rely on what is on disk
is valid. As a result, if the inode was written and contains
unlogged changes, the unlogged changes are lost, thereby violating
sync semantics.

The fix is to always issue a transaction after the buftarg flush
occurs is the log iѕ not idle or covered. This results in a dummy
transaction being written that contains the up-to-date log tail
value, which will be very recent. Indeed, it will be at least as
recent as the old code would have left on disk, so log recovery
will behave exactly as it used to in this situation.
Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarAlex Elder <aelder@sgi.com>
      b6f8dd49
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7