Factor out the functionality for adding and removing a single
socket, thereby allowing SoCs to individually register each
socket. The advantage of this approach is that SoCs can then
extend soc_pcmcia_socket as they wish.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Convert soc_common.c to be a stand alone module, rather than wrapping
it up into the individual SoC specific base modules. In doing this,
we need to add init/exit functions for soc_common to register/remove
the cpufreq notifier.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
As suggested by Wolfram Sang <w.sang@pengutronix.de>, use dev_dbg(),
and dev_{err,warn,info}() in pd6729.c, and add some "\n" suggested by
Komuro <komurojun-mbn@nifty.com>. In the ISR, use pr_devel() and
dev_vdbg() as they are only compiled if DEBUG (or, for dev_vdbg(),
VERBOSE_DEBUG) are set explicitly.
CC: Komuro <komurojun-mbn@nifty.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
As all in-tree drivers have been converted to not use cs_error() any more,
drop these functions and definitions, and update the Documentation.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of
requiring manual settings of PCMCIA_DEBUG.
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: linux-mtd@lists.infradead.org
CC: linux-usb@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of
requiring manual settings of PCMCIA_DEBUG.
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: linux-serial@vger.kernel.org
CC: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of
requiring manual settings of PCMCIA_DEBUG.
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: linux-scsi@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of
requiring manual settings of PCMCIA_DEBUG.
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: linux-wireless@vger.kernel.org
CC: netdev@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of
requiring manual settings of PCMCIA_DEBUG.
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: linux-wireless@vger.kernel.org
CC: netdev@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of
requiring manual settings of PCMCIA_DEBUG. Only some rare debug checks are
now hidden behind "#ifdef DEBUG" or "#if 0".
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: netdev@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of
requiring manual settings of PCMCIA_DEBUG.
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of
requiring manual settings of PCMCIA_DEBUG. Only some rare extra debug checks
in cm4000_cs.c cm4040_cs.c are now hidden behind a "#ifdef CM4000_DEBUG"
or "#ifdef CM4040_DEBUG".
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: Harald Welte <laforge@gnumonks.org>
CC: Jiri Kosina <jkosina@suse.cz>
CC: David Sterba <dsterba@suse.cz>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: linux-bluetooth@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
ide-cs.c is the only PCMCIA device driver making use of CONFIG_PCMCIA_DEBUG,
so convert it to use the dynamic debug infrastructure.
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: linux-ide@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Make use of the dynamic debug infrastructure in various PCMCIA socket
drivers. By doing so, only the drivers relying on soc_common make use
of CONFIG_PCMCIA_DEBUG. Therefore, update the Kconfig entry accordingly.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Use the generic "dynamic debug" infrastructure instead of
CONIG_PCMCIA_DEBUG in the PCMCIA core (pcmcia.ko and pcmcia_core.ko). To
enable debugging, enable CONFIG_DYNAMIC_DEBUG, mount debugfs and
$ echo -n 'module pcmcia_core +p' > /sys/kernel/debug/dynamic_debug/control
for the complete module "pcmcia_core", for example. For more detailled
instructions, please see Documentation/dynamic-debug-howto.txt
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
SSB is a prime example of how to make use of the new CIS helpers.
CC: Michael Buesch <mb@bu3sch.de>
Acked-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Use the new CIS helpers in net pcmcia drivers, which allows for
a few code cleanups.
This revision does not remove the phys_addr assignment in
3c589_cs.c -- a bug noted by Komuro <komurojun-mbn@nifty.com>
CC: David S. Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
As a replacement to pcmcia_get_{first,next}_tuple() and
pcmcia_get_tuple_data(), three new -- and easier to use --
functions are added:
- pcmcia_get_tuple() to get the very first CIS entry of one
type.
- pcmcia_loop_tuple() to loop over all CIS entries of one type.
- pcmcia_get_mac_from_cis() to read out the hardware MAC address
from CISTPL_FUNCE.
Only a handful of drivers need these functions anyway, as most
CIS access is already handled by pcmcia_loop_config(), which
now shares the same backed (pccard_loop_tuple()) with
pcmcia_loop_tuple().
A pcmcia_get_mac_from_cis() bug noted by Komuro
<komurojun-mbn@nifty.com> has been fixed in this revision.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Within the pcmcia_loop_config() callback, we already have all
tuple data available we need. Also add a fix to release the IO
resource (at least within pcmcia_loop_config() error path).
CC: Jiri Kosina <jkosina@suse.cz>
CC: David Sterba <dsterba@suse.cz>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Use pcmcia_loop_config() in a few drivers missed during the first
round. On fmvj18x_cs.c it -- strangely -- only requries us to set
conf.ConfigIndex, which is done by the core, so include an empty
loop function which returns 0 unconditionally.
CC: David S. Miller <davem@davemloft.net>
CC: David Sterba <dsterba@suse.cz>
CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
For the ipwireless part: Acked-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
A few PCMCIA network drivers can make use of values provided by the pcmcia
core, instead of tedious, independent CIS parsing.
xirc32ps_cs.c: manf_id
hostap_cs.c: multifunction count
b43/pcmcia.c: ConfigBase address and "Present"
smc91c92_cs.c: By default, mhz_setup() can use VERS_1 as it is stored
in struct pcmcia_device. Only some cards require workarounds, such as
reading out VERS_1 twice.
CC: David S. Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
Acked-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Christian Pellegrin <chripell@fsfe.org>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is no good reason to not support userspace specifying the
network namespace during device creation, and it makes it easier
to create a network device and pass it to a child network namespace
with a well known name.
We have to be careful to ensure that the target network namespace
for the new device exists through the life of the call. To keep
that logic clear I have factored out the network namespace grabbing
logic into rtnl_link_get_net.
In addtion we need to continue to pass the source network namespace
to the rtnl_link_ops.newlink method so that we can find the base
device source network namespace.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
or it will taint the kernel and fail to load becuase
of_address_to_resource() is GPL only.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
is thrown when the CAN device is registered due to insufficient
skb space, as reported by various users. This patch adds the
rtnl_link_ops "get_size" to fix the problem. I think this patch
is required for more recent kernels as well, even if no WARN_ON
dumps are triggered. Maybe we also need "get_xstats_size" for
the CAN xstats.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit fba4ed030c ("gianfar: Add Multiple
Queue Support") introduced the following warnings:
CHECK gianfar.c
gianfar.c:333:8: warning: incorrect type in assignment (different address spaces)
gianfar.c:333:8: expected unsigned int [usertype] *baddr
gianfar.c:333:8: got unsigned int [noderef] <asn:2>*<noident>
[... 67 lines skipped ...]
gianfar.c:2565:3: warning: incorrect type in argument 1 (different type sizes)
gianfar.c:2565:3: expected unsigned long const *addr
gianfar.c:2565:3: got unsigned int *<noident>
CC gianfar.o
gianfar.c: In function 'gfar_probe':
gianfar.c:985: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c:985: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c:993: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c:993: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c: In function 'gfar_configure_coalescing':
gianfar.c:1680: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c:1680: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c:1688: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c:1688: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c: In function 'gfar_poll':
gianfar.c:2565: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c:2565: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
gianfar.c:2566: warning: passing argument 2 of 'test_bit' from incompatible pointer type
gianfar.c:2585: warning: passing argument 2 of 'set_bit' from incompatible pointer type
Following warnings left unfixed (looks like sparse doesn't like
locks in loops, so __acquires/__releases() doesn't help):
gianfar.c:441:40: warning: context imbalance in 'lock_rx_qs': wrong count at exit
gianfar.c:441:40: context '<noident>': wanted 0, got 1
gianfar.c:449:40: warning: context imbalance in 'lock_tx_qs': wrong count at exit
gianfar.c:449:40: context '<noident>': wanted 0, got 1
gianfar.c:458:3: warning: context imbalance in 'unlock_rx_qs': __context__ statement expected different context
gianfar.c:458:3: context '<noident>': wanted >= 0, got -1
gianfar.c:466:3: warning: context imbalance in 'unlock_tx_qs': __context__ statement expected different context
gianfar.c:466:3: context '<noident>': wanted >= 0, got -1
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes following warnings:
fsl_pq_mdio.c:112:38: warning: cast adds address space to expression (<asn:2>)
fsl_pq_mdio.c:124:38: warning: cast adds address space to expression (<asn:2>)
fsl_pq_mdio.c:133:38: warning: cast adds address space to expression (<asn:2>)
fsl_pq_mdio.c:414:11: warning: cast adds address space to expression (<asn:2>)
Instead of adding __force all over the place, introduce convenient
fsl_pq_mdio_get_regs() call that does the ugly casting just once.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 1d2397d742 ("fsl_pq_mdio: Add
Suport for etsec2.0 devices") introduced the following warnings:
CHECK fsl_pq_mdio.c
fsl_pq_mdio.c:287:22: warning: incorrect type in initializer (different base types)
fsl_pq_mdio.c:287:22: expected unknown type 11 const *__mptr
fsl_pq_mdio.c:287:22: got unsigned long long [unsigned] [assigned] [usertype] addr
fsl_pq_mdio.c:287:19: warning: incorrect type in assignment (different base types)
fsl_pq_mdio.c:287:19: expected unsigned long long [unsigned] [usertype] ioremap_miimcfg
fsl_pq_mdio.c:287:19: got struct fsl_pq_mdio *<noident>
CC fsl_pq_mdio.o
fsl_pq_mdio.c: In function 'fsl_pq_mdio_probe':
fsl_pq_mdio.c:287: warning: initialization makes pointer from integer without a cast
fsl_pq_mdio.c:287: warning: assignment makes integer from pointer without a cast
These warnings are not easy to fix without ugly __force casts. So,
instead of introducing the casts, rework the code to substitute an
offset from an already mapped area. This makes the code a lot simpler
and less duplicated.
Plus, from now on we don't actually map reserved registers on
non-etsec2.0 devices, so we have more chances to catch programming
errors.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The Hauppauge WinTV HVR-1150 retail boards require the FORCE_TS_VALID bit
to be set in order to function properly. This change will work on the early
revisions on the board as well, but the final revision will not function
without this change.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When FORCE_TS_VALID mode is enabled, the saa713x will accept MPEG TS input
without requiring TS_VALID set high. This is required for some new boards
to function properly, due to the hardware design implementation.
The configuration is toggled within the board setup configuration. Boards
that do not have this bit set will function as before with no change.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The abs() macro has changed in 2.6.32 and returns a long instead of an
int. Fix the driver to avoid compilation warnings.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The FIX_BANDWIDTH quirk tries to work around cameras requesting the
maximum bandwidth regardless of the image size by computing a bandwidth
estimate. This works only for uncompressed frames.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Which is why I have always preferred sizeof(struct foo) over
sizeof(var).
Cc: Antti Palosaari <crope@iki.fi>
Acked-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_mr97310a: Change vstart for CIF sensor type 1 cams
This fixes the distortion at the end of the frame, and avoids the bad frame
dropping done because of this distortion, trippling the framerate!
Signed-off-by: Theodore Kilgore <kilgota@banach.math.auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds a vflip quirk for the Fujitsu Amilo Xi 2528. Thanks to Evgeny for the report.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds another vflip quirk for the MSI GX700.
Thanks to John Katzmaier for reporting.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds a vflip quirk for the Bruneinit laptop. Thanks to Jörg for the report
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since 2.6.32(-rc1), DVB core checks the return value of
dvb_frontend_ops.set_frontend. Now it becomes apparent that firedtv
always returned a bogus value from its set_frontend method.
CC: stable@kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This solves a problem in firedtv that has become major for Swedish DVB-T
users the last month or so. It will most likely solve issues seen by
other users as well.
If the length of an AVC message is greater than 127, the length field
should be encoded in LV mode instead of V mode. V mode can only be used
if the length is 127 or less. This patch ensures that the CA_PMT
message is always encoded in LV mode so PMT message of greater lengths
can be supported.
Signed-off-by: Henrik Kurelid <henrik@kurelid.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The s2255 driver had logic which aborted processing of a video frame
if there was no process waiting on the video buffer in question. That
simply doesn't work when the application is doing things in an
asynchronous manner. If the application went to the trouble to queue
the buffer in the first place, then the driver should always attempt
to complete it - even if the application at that moment has its
attention turned elsewhere. Applications which always blocked waiting
for I/O on the capture device would not have been affected by this.
Applications which *mostly* blocked waiting for I/O on the capture
device probably only would have been somewhat affected (frame lossage,
at a rate which goes up as the application blocks less). Applications
which never blocked on the capture device (e.g. polling only) however
would never have been able to receive any video frames, since in that
case this "is anyone waiting on this?" check on the buffer never would
have evalutated true. This patch just deletes that harmful check
against the buffer's wait queue.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
CC: stable@kernel.org
Add support for three new Hauppauge Device USB IDs:
2040:b900
2040:b910
2040:c000
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Because the counters were not reset when starting up streaming, they would
be reused from the previous run. This can result in cases such that when the
second instance of streaming starts up, the "cnt" variable in
em28xx_audio_isocirq() can end up being negative, resulting in attempting to
write to memory before the start of runtime->dma_area (as well as having a
negative number of bytes to copy).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bttv driver function which handles switching of the video standard
(set_tvnorm() in bttv-driver.c) includes a check which can optionally
also reset the cropping configuration to a default value. It is
"optional" based on a comparison of the cropcap parameters of the
previous vs the newly requested video standard. The comparison is
being done with a memcmp(), a function which only returns a true value
if the comparison actually fails.
This if-statement appears to have been written to assume wrong
memcmp() semantics. That is, it was re-initializing the cropping
configuration only if the new video standard did NOT have different
cropcap values. That doesn't make any sense. One definitely should
reset things if the cropcap parameters are different - if there's any
comparison to made at all.
The effect of this problem was that a transition from, say, PAL to
NTSC would leave in place old cropping setup that made sense for the
PAL geometry but not for NTSC. If the application doesn't care about
cropping it also won't try to reset the cropping configuration,
resulting in an improperly cropped video frame. In the case I was
testing this actually caused black video frames to be displayed.
Another interesting effect of this bug is that if one does something
which does NOT change the video standard and this function is run,
then the cropping setup gets reset anyway - again because of the
backwards comparison. It turns out that just running anything which
merely opens and closes the video device node (e.g. v4l-info) will
cause this to happen. One can argue that simply opening the device
node and not doing anything to it should not mess with any of its
state - but because of this behavior, any TV app which does such
things (e.g. xawtv) probably therefore doesn't see the problem.
The solution is to fix the sense of the if-statement. It's easy to
see how this mistake could have been made given how memcmp() works.
The patch is therefore removal of a single "!" character from the
if-statement in set_tvnorm in bttv-driver.c.
Signed-off-by: Mike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
