[Mike Frysinger <vapier.adi@gmail.com>:
- setup P_DEFAULT_BOOT_SPI_CS for every arch based on
the default bootrom behavior and convert all our boards
to it
- revert previous anomaly change ... bf51x is not affected
by anomaly 05000353]
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier.adi@gmail.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
remove subscribers-only marking as the list is
automatically & silently moderated for people
Signed-off-by: Mike Frysinger <vapier.adi@gmail.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
merge more of the bf54x and !bf54x gpio code together to
cut down on #ifdef mess
Signed-off-by: Mike Frysinger <vapier.adi@gmail.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
According to the documentation gpio_free should only be called from task
context only. To make this more explicit add a might sleep to all
implementations.
This patch changes the gpio_free implementations for the blackfin
architecture.
Signed-off-by: Uwe Kleine-Koenig <ukleinek@strlen.de>
Cc: David Brownell <david-b@pacbell.net>
Acked-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Make sure we don't accidently re-enable interrupts if we are being
called in atomic context
Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
when requesting a GPIO for the first time, the POLAR setting is not
set to a sane state. this can lead to indeterminate behavior that
cannot be resolved without an explicit write to the Blackfin port POLAR
register.
when requesting a GPIO for the first time via gpio_request(), the POLAR
setting for the GPIO in question should be set to sane state. this
should occur if the GPIO has not been allocated in any other way.
some examples:
- when doing something like "request_irq(); gpio_request();" on the
same GPIO, the POLAR setting should not be reset.
- when doing "gpio_request(); gpio_request();" on the same GPIO, the
POLAR setting should be reset only the first time and not the second.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
On BF561 EBIU_SDGCTL bit 31 controls the SDRAM external data
path width, typically set 0 for a 32-bit bus width. On other
Blackfin derivatives this bit should be set by default.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Dmacopy failed in BF537-STAMP when copy from SRAM to SDRAM and kernel
will reboot automatically.
Fixing by doing a SSYNC before mucking with DMA registers
Signed-off-by: Mike Frysinger <vapier.adi@gmail.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Commit 05fe478dd0 introduced some
@wbc->nr_to_write breakage.
It made the following changes:
1. Decrement wbc->nr_to_write instead of nr_to_write
2. Decrement wbc->nr_to_write _only_ if wbc->sync_mode == WB_SYNC_NONE
3. If synced nr_to_write pages, stop only if if wbc->sync_mode ==
WB_SYNC_NONE, otherwise keep going.
However, according to the commit message, the intention was to only make
change 3. Change 1 is a bug. Change 2 does not seem to be necessary,
and it breaks UBIFS expectations, so if needed, it should be done
separately later. And change 2 does not seem to be documented in the
commit message.
This patch does the following:
1. Undo changes 1 and 2
2. Add a comment explaining change 3 (it very useful to have comments
in _code_, not only in the commit).
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Acked-by: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The @fnac.net will be shut down within a couple of months, so fix my
email address.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'linux-next' of git://git.infradead.org/ubifs-2.6:
UBIFS: remove fast unmounting
UBIFS: return sensible error codes
UBIFS: remount ro fixes
UBIFS: spelling fix 'date' -> 'data'
UBIFS: sync wbufs after syncing inodes and pages
UBIFS: fix LPT out-of-space bug (again)
UBIFS: fix no_chk_data_crc
UBIFS: fix assertions
UBIFS: ensure orphan area head is initialized
UBIFS: always clean up GC LEB space
UBIFS: add re-mount debugging checks
UBIFS: fix LEB list freeing
UBIFS: simplify locking
UBIFS: document dark_wm and dead_wm better
UBIFS: do not treat all data as short term
UBIFS: constify operations
UBIFS: do not commit twice
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2:
ocfs2: add quota call to ocfs2_remove_btree_range()
ocfs2: Wakeup the downconvert thread after a successful cancel convert
ocfs2: Access the xattr bucket only before modifying it.
configfs: Silence lockdep on mkdir(), rmdir() and configfs_depend_item()
ocfs2: Fix possible deadlock in ocfs2_write_dquot()
ocfs2: Push out dropping of dentry lock to ocfs2_wq
* 'for-linus' of git://oss.sgi.com/xfs/xfs:
[XFS] Warn on transaction in flight on read-only remount
xfs: Check buffer lengths in log recovery
don't reallocate sxp variable passed into xfs_swapext
This builds upon eeabac7386
("sparc64: Validate kernel generated fault addresses on sparc64.")
Upon further consideration, we actually should never see any
fault addresses for 32-bit tasks with the upper 32-bits set.
If it does every happen, by definition it's a bug. Whatever
context created that fault would only have that fault satisfied
if we used the full 64-bit address. If we truncate it, we'll
always fault the wrong address and we'll always loop faulting
forever.
So catch such conditions and mark them as errors always. Log
the error and fail the fault.
Signed-off-by: David S. Miller <davem@davemloft.net>
On machine were no IO ports are assigned the call
to pci_enable_device() will fail, even if need_ioport
is false, we need to use pci_enable_device_mem() here.
Signed-off-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
A recent patch by Stephen Hemminger to convert XPNET to use net_device_ops and
internal net_device_stats failed to link the net_device_ops structure to the
net_device structure. See commit e8ac9c55f2
("xpnet: convert devices to new API").
Signed-off-by: Dean Nelson <dcn@sgi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
S2IO driver is printing dev->name before the name being allocated, which
display eth%d instead of eth0, eth1, etc. Example:
eth%d: Enabling MSIX failed
eth%d: MSI-X requested but failed to enable
This patch just change eth%d to s2io.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds a few device ID's. It also removes an ID that was used
in an internal engineering version of a device and will never see
commercial light. Even if this ID will be 'recycled' in the future,
which is very unlikely, we don't know what kind of device will be
behind it. Therefore it's safer to remove it.
Signed-off-by: Filip Aben <f.aben@option.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Read configuration register during probe and use it to size the
available VPD. Move existing code using same register slightly
earlier in probe handling.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The VPD stuff has more data and isn't generally that useful, so move
it into the existing debugfs display and use the new PCI VPD
accessor routines.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On non-x86 platforms it is possible to run out of DMA mapping resources.
The driver was ignoring this and could cause corruptions.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This workaround is not needed. It was inherited from sk98lin driver but only
applies to an early development version of the chip that is not supported
by sky2. The workaround required an unnecessary pci read which hurts performance
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Till VFS can correctly support read-only remount without racing,
use WARN_ON instead of BUG_ON on detecting transaction in flight
after quiescing filesystem.
Signed-off-by: Felix Blyakher <felixb@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Before trying to obtain, read or write a buffer,
check that the buffer length is actually valid. If
it is not valid, then something read in the recovery
process has been corrupted and we should abort
recovery.
Reported-by: Eric Sesterhenn <snakebyte@gmx.de>
Tested-by: Eric Sesterhenn <snakebyte@gmx.de>
Reviewed-by: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Felix Blyakher <felixb@sgi.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Felix Blyakher <felixb@sgi.com>
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
libata: implement HORKAGE_1_5_GBPS and apply it to WD My Book
libata: add no penalty retry request for EH device handling routines
libata: improve probe failure handling
libata: add @spd_limit to sata_down_spd_limit()
libata: clear dev->ering in smarter way
libata: check onlineness before using SPD in sata_down_spd_limit()
libata: move ata_dev_disable() to libata-eh.c
libata: fix EH device failure handling
sata_nv: ck804 has borked hardreset too
ide/libata: fix ata_id_is_cfa() (take 4)
libata: fix kernel-doc warnings
ahci: add a module parameter to ignore the SSS flags for async scanning
sata_mv: Fix chip type for Hightpoint RocketRaid 1740/1742
[libata] sata_sil: Fix compilation error with libata debugging enabled
Michael Tokarev wrote:
[]
> 2, and this is the main one: How about supplementary groups?
>
> Here I have a valid usage case: a group of testers running various
> versions of windows using KVM (kernel virtual machine), 1 at a time,
> to test some software. kvm is set up to use bridge with a tap device
> (there should be a way to connect to the machine). Anyone on that group
> has to be able to start/stop the virtual machines.
>
> My first attempt - pretty obvious when I saw -g option of tunctl - is
> to add group ownership for the tun device and add a supplementary group
> to each user (their primary group should be different). But that fails,
> since kernel only checks for egid, not any other group ids.
>
> What's the reasoning to not allow supplementary groups and to only check
> for egid?
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change spin_locks to irqsave to prevent dead-locks.
Protect adding and deleting to/from dca_providers list.
Drop the lock during dca_sysfs_add_req() and dca_sysfs_remove_req() calls
as they might sleep (use GFP_KERNEL allocation).
Signed-off-by: Maciej Sosnowski <maciej.sosnowski@intel.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The netlink connector uses its own workqueue to relay the datas sent
from userspace to the appropriate callback. If you launch the test
from Documentation/connector and change it a bit to send a high flow
of data, you will see thousands of events coming to the "cqueue"
workqueue by looking at the workqueue tracer.
This flow of events can be sent very quickly. So, to not encumber the
kevent workqueue and delay other jobs, the "cqueue" workqueue should
remain.
But this workqueue is pointless most of the time, it will always be
created (assuming you have built it of course) although only
developpers with specific needs will use it.
So avoid this "most of the time useless task", this patch proposes to
create this workqueue only when needed once. The first jobs to be
sent to connector callbacks will be sent to kevent while the "cqueue"
thread creation will be scheduled to kevent too.
The following jobs will continue to be scheduled to keventd until the
cqueue workqueue is created, and then the rest of the jobs will
continue to perform as usual, through this dedicated workqueue.
Each time I tested this patch, only the first event was sent to
keventd, the rest has been sent to cqueue which have been created
quickly.
Also, this patch fixes some trailing whitespaces on the connector files.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
while (limit--)
if (test())
break;
if (limit <= 0)
goto test_failed;
In the last iteration, limit is decremented after the test to 0.
If just thereafter test() succeeds and a break occurs, the goto
still occurs because limit is 0.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In order to handle all of the cases of address calculation overflow
properly, we run sparc 32-bit processes in "address masking" mode
when running on a 64-bit kernel.
Address masking mode zeros out the top 32-bits of the address
calculated for every load and store instruction.
However, when we're in privileged mode we have to run with that
address masking mode disabled even when accessing userspace from
the kernel.
To "simulate" the address masking mode we clear the top-bits by
hand for 32-bit processes in the fault handler.
It is the responsibility of code in the compat layer to properly
zero extend addresses used to access userspace. If this isn't
followed properly we can get into a fault loop.
Say that the user address is 0xf0000000 but for whatever reason
the kernel code sign extends this to 64-bit, and then the kernel
tries to access the result.
In such a case we'll fault on address 0xfffffffff0000000 but the fault
handler will process that fault as if it were to address 0xf0000000.
We'll loop faulting forever because the fault never gets satisfied.
So add a check specifically for this case, when the kernel is faulting
on a user address access and the addresses don't match up.
This code path is sufficiently slow path, and this bug is sufficiently
painful to diagnose, that this kind of bug check is warranted.
Signed-off-by: David S. Miller <davem@davemloft.net>
