Fixes this:

  drivers/char/ramoops.c: In function 'ramoops_init':
  drivers/char/ramoops.c:221: error: implicit declaration of function 'IS_ERR'
  drivers/char/ramoops.c:222: error: implicit declaration of function 'PTR_ERR'

If it actually builds on other platforms, it's probably getting
linux/err.h via some other #include.
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

On a recent compile, I got this warning:

  CC [M]  drivers/net/pcmcia/smc91c92_cs.o
drivers/net/pcmcia/smc91c92_cs.c: In function ‘smc91c92_probe’:
drivers/net/pcmcia/smc91c92_cs.c:812:12: warning: ‘j’ may be used uninitialized in this function

However, "j" is only used in a branch which has the same condition as
a previous branch, where j is set, e.g.

	int j;

	if (CONDITION)
	    j = VALUE

	...

	if (CONDITION)
	   printk(j)

Still, avoid this warning, as it is easy to circumvent.
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Without CONFIG_HERMES_PRISM, only match cards that have "Version 01.01"
as the third product ID.  Those have Agere firmware.

With CONFIG_HERMES_PRISM, match all 0x0156:0x0002 cards.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Cards with numeric ID 0x0156:0x0002 and third ID "Version 01.02" can be
assumed to have Intersil firmware.  Cards with Agere firmware use
"Version 01.01".
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Kill off the buff gpio as not used anywhere.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Now the are optional, let us get rid of the ones that don't have
any content.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

10 boards define these empty, probably indicating not everyone has a use for them.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

drivers/media/rc/ir-mce_kbd-decoder.c:446:16: error: expected declaration specifiers or '...' before string constant
drivers/media/rc/ir-mce_kbd-decoder.c:446:1: warning: data definition has no type or storage class
drivers/media/rc/ir-mce_kbd-decoder.c:446:1: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
drivers/media/rc/ir-mce_kbd-decoder.c:446:16: warning: function declaration isn't a prototype
drivers/media/rc/ir-mce_kbd-decoder.c:447:15: error: expected declaration specifiers or '...' before string constant
drivers/media/rc/ir-mce_kbd-decoder.c:447:1: warning: data definition has no type or storage class
drivers/media/rc/ir-mce_kbd-decoder.c:447:1: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
drivers/media/rc/ir-mce_kbd-decoder.c:447:15: warning: function declaration isn't a prototype
drivers/media/rc/ir-mce_kbd-decoder.c:448:20: error: expected declaration specifiers or '...' before string constant
drivers/media/rc/ir-mce_kbd-decoder.c:448:1: warning: data definition has no type or storage class
drivers/media/rc/ir-mce_kbd-decoder.c:448:1: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
drivers/media/rc/ir-mce_kbd-decoder.c:448:20: warning: function declaration isn't a prototype
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/video/ov5642.c:985:1: warning: data definition has no type or storage class
drivers/media/video/ov5642.c:985:1: warning: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE'
drivers/media/video/ov5642.c:985:1: warning: parameter names (without types) in function declaration
drivers/media/video/ov5642.c: In function 'ov5642_mod_init':
drivers/media/video/ov5642.c:998:9: error: 'THIS_MODULE' undeclared (first use in this function)
drivers/media/video/ov5642.c:998:9: note: each undeclared identifier is reported only once for each function it appears in
drivers/media/video/ov5642.c: At top level:
drivers/media/video/ov5642.c:1009:20: error: expected declaration specifiers or '...' before string constant
drivers/media/video/ov5642.c:1009:1: warning: data definition has no type or storage class
drivers/media/video/ov5642.c:1009:1: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
drivers/media/video/ov5642.c:1009:20: warning: function declaration isn't a prototype
drivers/media/video/ov5642.c:1010:15: error: expected declaration specifiers or '...' before string constant
drivers/media/video/ov5642.c:1010:1: warning: data definition has no type or storage class
drivers/media/video/ov5642.c:1010:1: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
drivers/media/video/ov5642.c:1010:15: warning: function declaration isn't a prototype
drivers/media/video/ov5642.c:1011:16: error: expected declaration specifiers or '...' before string constant
drivers/media/video/ov5642.c:1011:1: warning: data definition has no type or storage class
drivers/media/video/ov5642.c:1011:1: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
drivers/media/video/ov5642.c:1011:16: warning: function declaration isn't a prototype
drivers/media/video/ov5642.c: In function 'ov5642_mod_init':
drivers/media/video/ov5642.c:999:1: warning: control reaches end of non-void function
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Only Sparc and PPC actually have the asm/prom.h include and as such they
can't be moved outside of the ifdefs.
Reported-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Several vendors implement a second configuration register, which we
check during device detection. Refactor the code to avoid duplication.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Stijn Devriendt <sdevrien@cisco.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

With a device ID register value of 0, the SA56004 detection is rather
weak. Check several other register too to confirm the detection, as we
do for other supported devices.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Stijn Devriendt <sdevrien@cisco.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: NStijn Devriendt <sdevrien@cisco.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

The optional extended local temperature register can never have
address 0, as this address is already used by another register. Thus
we can get rid of flag LM90_HAVE_LOCAL_EXT and simply rely on
reg_local_ext being non-zero to determine if a given chip has this
extension or not. This makes the code more simple.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Stijn Devriendt <sdevrien@cisco.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

PMBus client driver supporting National Semiconductor LM25066, LM5064, and LM5066.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

Add support for voltage, current, and temperature peak (historic maximum)
attributes.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

Add support for voltage, current, and temperature peak (historic maximum)
attributes.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

Add support for voltage and temperature peak (historic maximum) attributes.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

Add support for voltage and current peak (historic maximum) attributes.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

Most PMBus devices provide manufacturer specific commands to read low and/or
high peak values for some or all of its sensors.

To support providing those values as lowest/highest attributes to the user,
introduce virtual PMBus commands. Those commands reside outside the normal
command set and have to be implemented in device specific code, which map the
virtual commands to device specific commands.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

With virtual register page support, it is now possible that the status register
on virtual pages does not exist or is itself virtual. To take this into account
when creating alarm attributes, generate those attributes only if the status
register on the respective page is known to exist.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

Some PMBus chips have non-standard sensor registers. An easy way to
support such sensors is to introduce virtual pages and map the non-standard
registers into standard registers on an extra page.

For this to work, the code verifying if the configured number of pages exists
has to be removed. Since a wrong number of pages can only be configured in a
front-end driver, this should not have a practical impact since the resulting
errors should be found during development and testing.

Also, functions to read the chip status while checking if a command register
exists must be modified to no longer set the page register before reading the
status, since the physical page associated with the checked register may not
exist. This does not make a functional difference since the page was already set
when the attempt to read the register was made.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

Some PMBus devices use non-standard registers for some of the sensors and/or
limits. To support such devices, add code to support reading and writing of word
size registers in device specific code.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

Some hwmon sysfs attributes have a length of 20 bytes (plus terminating 0).
I2C_NAME_SIZE is defined as 20 and thus can not be used to define the length
of hwmon sysfs attributes. Replace it with PMBUS_NAME_SIZE, set to 24.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

Add ADP4000, NCP4200 and NCP4208 to the list of devices supported by the generic
PMBus driver, and add device IDs to enable explicit instantiation.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>
Acked-by: NJean Delvare <khali@linux-fr.org>

In VID mode, output voltages are measured and reported as VID values, and
have to be converted to voltages using VID conversion tables or functions.
Support is added for VR11 only at this time.

This patch enables support for PMBus devices supporting VID VR11 based output
voltage selection such as NCP4200 and NCP4208.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

The logic at em28xx_isoc_dvb_max_packetsize() sucks, at least for newer
the needed packet size. Yet, it is better than nothing.

Rewrite the code in order to change the default to 752 for em2884 and
newer chips and provide a better way to handle per-chipset specifics.

For em2874, the current default should be enough, as the only em2874
board is currently a 1-seg ISDB-T board, so, it needs only a limited
amount of bandwidth.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently, the driver assumes that all QAM carriers are spaced with
8MHz. This is wrong, and may decrease QoS on Countries like Brazil,
that have DVB-C carriers with 6MHz-spaced.

Fortunately, both ITU-T J-83 and EN 300 429 specifies a way to
associate the symbol rate with the bandwidth needed for it.

For ITU-T J-83 2007 annex A, the maximum symbol rate for 6 MHz is:
	6 MHz / 1.15 = 5217391 Bauds
For  ITU-T J-83 2007 annex C, the maximum symbol rate for 6 MHz is:
	6 MHz / 1.13 = 5309735 Bauds.

As this tuner is currently used only for DRX-K, and it is currently
hard-coded to annex A, I've opted to use the roll-off factor of 0.15,
instead of 0.13.

If we ever support annex C, the better would be to add a DVB S2API
call to allow changing between Annex A and C, and add the 0.13 roll-off
factor to it.

This code is currently being used on other frontends, so I think we
should later add a core function with this code, to warrant that
it will be properly implemented everywhere.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Since the number of PMBus drivers is getting large, move them into
directory drivers/hwmon/pmbus to improve readability and scalability.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: NRobert Coulson <robert.coulson@ericsson.com>

A small modification was necessary since in the machine description
for 'n2cp' and 'ncp' nodes, there no longer is an 'intr' property.

That's OK because this property was always nothing more than an
array of integers '1' ... 'nr_inos + 1' so we can just compute it
in-place.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

And stop referring to Victoria Falls, as the attribute we're
talking about is whether the rng is multi-unit capable which
applies to several chip variants now.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Cleanup to:

- have selection for all types of frames, not just FCP.
- remove redundant cpu_online check once fcoe_select_cpu called
  as this is not required since later code flow check for offlined
  cpu.
- Simplify fcoe_select_cpu() by removing unnecessary checks to
  skip curr_cpu, this also fixes possibly infinite loop in case
  of curr_cpu is the only cpu while iterating in the loop.

This cleanup mainly applies to target as incoming request are
mostly for target, therefore Kiran has verified the patch
with target also.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NKiran Patil <kiran.patil@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Use pending queue to retry FIP frame in case its tx
fails and use common pending queue for both fcoe
and fip frames using fcoe_port_send.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The lport retry timer hits warn on in case
it has become ready in response from fip
login from fcoe_ctlr_flogi_send(), this is
possible but safe code path, therefore
removing this warn on.

Jun 22 03:16:30 10.0.16.6 [488198.316517] host3: Assigned Port ID 180f02
Jun 22 03:16:32 10.0.16.6 [488200.091561] ------------[ cut here ]------------
Jun 22 03:16:32 10.0.16.6 [488200.091586] WARNING: at
drivers/scsi/libfc/fc_lport.c:1355 fc_lport_timeout+0xd9/0xe0 [libfc]()
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

fc_queuecommand() allocates an FCP packet for each SCSI command and sends
it out on the wire. In the process it stores the reference to the FCP packet
in the scsi_cmnd structure.
Now, in case under stress testing the libfc exchange layer runs out of
exchanges the fc_queuecommand() may not be able to send out commands out on
the wire. In such a scenario if there is an error in sending the FCP packet
out the wire; fc_queuecommand() deletes the FCP packet from internal queue,
releases the FCP packet and returns a SCSI_MLQUEUE_HOST_BUSY status to the
scsi-ml. But, the reference to the FCP packet set in the scsi_cmnd is not
removed from the scsi_cmnd in this code path.

This might lead to a crash under stress testing where the scsi_cmnd failed by
fc_queuecommand() comes up to fc_eh_abort() via scsi eh thread. fc_eh_abort()
will get reference to the FCP packet to be aborted from the scsi_cmnd for
further FCP abort related processing and then try to release the FCP packet
that has already been released.

This patch removes the FCP packet reference from the scsi_cmnd before returning
back from fc_queuecommand() in case of an error in sending out the FCP packet.
Signed-off-by: NNeerav Parikh <Neerav.Parikh@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The variable on stack, namely cdb_op, is not used but removed.

[ Patch reworked by Robert Love due to invalid patch format ]
Signed-off-by: NHillf Danton <dhillf@gmail.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

One change is to cleanup typo in comment for fc_fcp_recv(), another corrects
the misleading comment for fc_fcp_abts_resp().

[ Patch reworked by Robert Love due to invalid patch format ]
Signed-off-by: NHillf Danton <dhillf@gmail.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Drop the rx frame having xid with wrong cpu info
or received with xid  not matching to our xid.

Not dropping such frame is causing panic as
that causes accessing data struct beyond their
bounds.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

If fail to create workqueue, the newly created cache for exchg has to be
released.
Signed-off-by: NHillf Danton <dhillf@gmail.com>
Reviewed-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Though defined, FC_MAX_ERROR_CNT is not used. It is used now for CRC error in
the path of receiving FCP frame.
Signed-off-by: NHillf Danton <dhillf@gmail.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

There is no need to cache the ptype in fcoe_rcv_info struct as it is never
used anywhere.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>