If cpufreq_register_notifier() fails, we have to remove the port added by
sci_probe_single(), which is not done by sci_cleanup_single().

Else the serial port stays active from the point of view of the serial
subsystem, and it may crash when userspace getty is started, or when the
loadable driver module is unloaded.

This was introduced by commit 6dae1421
("serial: sh-sci: Fix probe error paths").
Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the serial port being removed is used as a console, it must also be
unregistered from the console subsystem using unregister_console().

uart_ops.release_port() will release resources (e.g. iounmap() the serial
port registers), causing a crash on subsequent kernel output if the console
is still registered.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95e629b7 removed the use of board
specific hooks in serial_at91.h, so now, the open/close hook are just
dead code.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For better consistency.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The 'active' sysfs attribute should refer to the currently active tty
devices the console is running on, not the currently active console. The
console structure doesn't refer to any device in sysfs, only the tty the
console is running on has. So we need to print out the tty names in
'active', not the console names.

There is one special-case, which is tty0. If the console is directed to
it, we want 'tty0' to show up in the file, so user-space knows that the
messages get forwarded to the active VT. The ->device() callback would
resolve tty0, though. Hence, treat it special and don't call into the VT
layer to resolve it (plymouth is known to depend on it).

Cc: Lennart Poettering <lennart@poettering.net>
Cc: Kay Sievers <kay@vrfy.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NWerner Fink <werner@suse.de>
Signed-off-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use devm_ioremap_resource() in order to make the code simpler and
it gives proper codes on errors.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The user-settable knob, low_latency, has been the source of
several BUG reports which stem from flush_to_ldisc() running
in interrupt context. Since 3.12, which added several sleeping
locks (termios_rwsem and buf->lock) to the input processing path,
the frequency of these BUG reports has increased.

Note that changes in 3.12 did not introduce this regression;
sleeping locks were first added to the input processing path
with the removal of the BKL from N_TTY in commit
a88a69c9,
'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
and later in commit 38db8979,
'tty: throttling race fix'. Since those changes, executing
flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.

However, since most devices do not validate if the low_latency
setting is appropriate for the context (process or interrupt) in
which they receive data, some reports are due to misconfiguration.
Further, serial dma devices for which dma fails, resort to
interrupt receiving as a backup without resetting low_latency.

Historically, low_latency was used to force wake-up the reading
process rather than wait for the next scheduler tick. The
effect was to trim multiple milliseconds of latency from
when the process would receive new data.

Recent tests [1] have shown that the reading process now receives
data with only 10's of microseconds latency without low_latency set.

Remove the low_latency rx steering from tty_flip_buffer_push();
however, leave the knob as an optional hint to drivers that can
tune their rx fifos and such like. Cleanup stale code comments
regarding low_latency.

[1] https://lkml.org/lkml/2014/2/20/434

"Yay.. thats an annoying historical pain in the butt gone."
	-- Alan Cox
Reported-by: NBeat Bolli <bbolli@ewanet.ch>
Reported-by: NPavel Roskin <proski@gnu.org>
Acked-by: NDavid Sterba <dsterba@suse.cz>
Cc: Grant Edwards <grant.b.edwards@gmail.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Hal Murray <murray+fedora@ip-64-139-1-69.sjc.megapath.net>
Cc: <stable@vger.kernel.org> # 3.12.x+
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a matching table for the the bcm63xx_uart driver on the compatible
string "brcm,bcm6345-uart" which covers all BCM63xx implementations and
reflects the fact that this block was first introduced with the BCM6345
SoC.  Also make sure that we convert the id based on the uart aliases
provided by the relevant Device Tree.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bcm63xx_uart driver uses RSET_UART_SIZE which is a constant defined
for MIPS-based BCM63xx platforms, pull this constant value from the
MIPS-specific header and put it in include/linux/serial_bcm63xx.h to
make the driver platform agnostic.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Include linux/io.h which provides the definition for
__raw_{readl,writel}, this is not necessary on MIPS since there is an
implicit inclusion, but it is on ARM for instance.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These can be used to send commands consisting of an arbitrary string to the
terminal, most often used to set a terminal's window title or to redefine
the colour palette.  Our console doesn't use OSC, unlike everything else,
which can lead to junk being displayed if a process sends such a code
unconditionally.

The rules for termination follow established practice rather than Ecma-48.
Ecma-48 requires the string to use only byte values 0x08..0x0D and
0x20..0x7E, terminated with either ESC \ or 0x9C.  This would disallow using
8-bit characters, which are reasonable for example in window titles.
A widespread idiom is to terminate with 0x07.  The behaviour for other
control characters differs between terminal emulators, I followed libvte and
xterm:
* 0x07 and ESC anything terminate
* nothing else terminates, all 8-bit values including 0x9C are considered a
  part of the string
Signed-off-by: NAdam Borowski <kilobyte@angband.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAdam Borowski <kilobyte@angband.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Every couple of months, someone sends a patch to fix:

drivers/tty/serial/8250/8250_core.c: In function 'serial_unlink_irq_chain':
drivers/tty/serial/8250/8250_core.c:1712:2: warning: 'i' may be used uninitialized in this function [-Wuninitialized]

and they in turn get a NACK for their efforts, and are told that
their compiler is broken.  This has been going on since at least
the year 2008:  https://lkml.org/lkml/2008/11/24/433

Lets add a comment, so that subsequent patches don't get as far as
the maintainers or the mailing lists.
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit d8a5dc30.

This breaks plymouth installs, either because plymouth is using the file
"incorrectly" or because the patch is incorrect.  Either way, this needs
to be reverted until it is all figured out.
Reported-by: NJosh Boyer <jwboyer@fedoraproject.org>
Reported-by: NRay Strode <halfline@gmail.com>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Kay Sievers <kay@vrfy.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Werner Fink <werner@suse.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This fixes bug introduced in 667a6b7a (regulator: max14577: Add missing
of_node_put). The DTS parsing function returned number of matched
regulators as success status which then was compared against 0 in probe.

Result was a probe fail after successful parsing the DTS:
max14577-regulator: probe of max14577-regulator failed with error 2
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviwed-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt
handler. The bridge interrupt is implemented using a single generic
chip. Thus the parameter passed to irq_get_domain_generic_chip()
should always be zero.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Fixes: 9dbd90f1 ("irqchip: Add support for Marvell Orion SoCs")
Cc: <stable@vger.kernel.org> # v3.11+
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

ENDPTFLUSH and ENDPTPRIME registers are set by software and clear
by hardware. There is a bit for each endpoint. When we are setting
a bit for an endpoint we should make sure we do not touch other
endpoint bit. There is a race condition if the hardware clear the
bit between the read and the write in hw_write.

Cc: stable <stable@vger.kernel.org> # 3.11+
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Tested-by: NMichael Grzeschik <mgrzeschik@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The change (008fa749) that moved the
node release code to a separate function broke death notifications in
some cases. When it encountered a reference without a death
notification request, it would skip looking at the remaining
references, and therefore fail to send death notifications for them.

Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Cc: stable <stable@vger.kernel.org> # 3.10
Signed-off-by: NArve Hjønnevåg <arve@android.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NJeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Most WDT driver modules return ENODEV during modprobe if
no valid device was found, but w83697hf_wdt returns EIO.

Let w83697hf_wdt return ENODEV.
Signed-off-by: NStanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

A documentation update exposed the existance of the turbo ratio
register. Update baytrail support to use the turbo range.
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

LFM (max efficiency ratio) is the max frequency at minimum voltage
supported by the processor.  Using LFM as the minimum P state
increases performmance without affecting power. By not using P states
below LFM we avoid using P states that are less power efficient.
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Change "dummy supplies not allowed" error message to warning instead, as this
is a just warning message with no change to the behavior.

[Added a CC to stable since some other bug fixes cause this to come up
more frequently on PCs which is how it was noticed -- broonie]
Signed-off-by: NShuah Khan <shuah.kh@samsung.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

Fix regression caused by commit b072e53b, which breaks loading nouveau
driver on optimus laptops.

On some platforms, ACPI _DSM method (nouveau_op_dsm_muid, function 0)
has special requirements on the fourth parameter, which is different
from ACPI specifications. So revert to the private implementation
to check availability of _DSM functions instead of using common
acpi_check_dsm() interface.

Fixes: b072e53b (ACPI / nouveau: replace open-coded _DSM code with helper functions)
Reported-and-tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
[rjw: Subject]
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

sparc_cpu_model isn't in asm/system.h any more, so remove a comment
about it.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: sparclinux@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

schedule_delayed_work() takes the delay in jiffies, not msecs.

This bug slipped in with the recent reset logic cleanup
(8ed1fb79: "usb: musb: finish suspend/reset work independently from
musb_hub_control()").
Signed-off-by: NDaniel Mack <daniel@zonque.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP.  In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.

Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
preprocessor conditional, and moving msm_hsusb_config_vddcx().

While we're here, eliminate the CONFIG_PM conditional for setting
up the dev_pm_ops.

This address the following errors Russell King has hit doing randconfig
builds:

drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function 'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of function 'msm_otg_resume'

Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NJosh Cartwright <joshc@codeaurora.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fix possible NULL pointer dereference introduced in
commit 219580e6 (usb: f_fs: check quirk to pad epout
buf size when not aligned to maxpacketsize)

In cases we do wait with:

wait_event_interruptible(epfile->wait, (ep = epfile->ep));

for endpoint to be enabled, functionfs_bind() has not been called yet
and epfile->ffs->gadget is still NULL and the automatic variable 'gadget'
has been initialized with NULL at the point of its definition.
Later on it is used as a parameter to:

usb_ep_align_maybe(gadget, ep->ep, len)

which in turn dereferences it.

This patch fixes it by moving the actual assignment to the local 'gadget'
variable after the potential waiting has completed.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We need to use gadget_is_otg to check if the gadget is really
otg support at runtime, other composite gadget drivers have already
followed this method.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As the lock might be used through DMA-API which is allowed
in interrupt context.
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
Acked-by: NWill Deacon <will.deacon@arm.com>

Adds a selftest function for the of_match_node function. of_match_node
is supposed to handle precedence for the compatible property as well as
the name and device_type values. This patch adds some test case data and
a function that makes sure each test node matches against the correct
entry of an of_device_id table.

This code was written to verify the new of_match_node() implementation
that is an earlier part of this series.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Cc: Kevin Hao <haokexin@gmail.com>

The testcase data is usable by any platform. This patch moves it into
the drivers/of directory so it can be included by any architecture.

Using the test cases requires manually adding #include <testcases.dtsi>
to the end of the boards .dtsi file and enabling CONFIG_OF_SELFTEST. Not
pretty though. A useful project would be to make the testcase code
easier to execute.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

In the current implementation of __of_match_node(), it will compare
each given match entry against all the node's compatible strings
with of_device_is_compatible().

To achieve multiple compatible strings per node with ordering from
specific to generic, this requires given matches to be ordered from
specific to generic. For most of the drivers this is not true and
also an alphabetical ordering is more sane there.

Therefore, we define a following priority order for the match, and
then scan all the entries to find the best match.
  1. specific compatible && type && name
  2. specific compatible && type
  3. specific compatible && name
  4. specific compatible
  5. general compatible && type && name
  6. general compatible && type
  7. general compatible && name
  8. general compatible
  9. type && name
  10. type
  11. name

v5: Fix nested locking bug
v4: Short-circuit failure cases instead of mucking with score, and
    remove extra __of_device_is_compatible() wrapper stub.
    Move scoring logic directly into __of_device_is_compatible()
v3: Also need to bail out when there does have a compatible member in match
    entry, but it doesn't match with the device node's compatible.
v2: Fix the bug such as we get the same score for the following two match
    entries with the empty node 'name2 { };'
	struct of_device_id matches[] = {
		{.name = "name2", },
		{.name = "name2", .type = "type1", },
		{}
	};
Signed-off-by: NKevin Hao <haokexin@gmail.com>
[grant.likely: added v4 changes]
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Tested-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Tested-by: NStephen Chivers <schivers@csc.com>
Tested-by: NSachin Kamat <sachin.kamat@linaro.org>

This reverts commit 2d4054d8 (ACPI: Blacklist Win8 OSI for some HP
laptop 2013 models) that is not necessary any more after previous
commit 1811fcb029fa (ACPI / video: Add systems that should favour native
backlight interface).
Requested-by: NTakashi Iwai <tiwai@suse.de>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some system's ACPI video backlight control interface is broken and the
native backlight control interface should be used by default. This patch
sets the use_native_backlight parameter to true for those systems so
that video backlight control interface will not be created. For detailed
models that are added here, reference the following list.

Note that the user specified kernel cmdline option will always have the
highest priority, i.e. if use_native_backlight=0 is specified and the
system is in the DMI table, the video module will not skip registering
backlight interface for it.

Thinkpad T430s:
Reported-by: NTheodore Tso <tytso@mit.edu>
Reported-and-tested-by: NPeter Weber <bugs@ttyhoney.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Thinkpad X230:
Reported-and-tested-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=51231
ThinkPad X1 Carbon:
Reported-and-tested-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
Lenovo Yoga 13:
Reported-by: NLennart Poettering <lennart@poettering.net>
Reported-and-tested-by: NKevin Smith <thirdwiggin@gmail.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=63811
Dell Inspiron 7520:
Reported-by: NRinat Ibragimov <ibragimovrinat@mail.ru>
Acer Aspire 5733Z:
Reported-by: <sov.info@mail.ru>
References: https://bugzilla.kernel.org/show_bug.cgi?id=62941
Acer Aspire V5-431:
Reported-by: NThomas Christensen <christensenthomas@gmail.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=68751
HP ProBook 4340s:
Reported-and-tested-by: NVladimir Sherenkov <a_12300@mail.ru>
References: http://redmine.russianfedora.pro/issues/1258
HP EliteBook/ProBook 2013 models, ZBook and some others:
Provided-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some devices have duplicate entries in there brightness levels table, ie
on my Dell Latitude E6430 the table looks like this:

[    3.686060] acpi backlight index   0, val 80
[    3.686095] acpi backlight index   1, val 50
[    3.686122] acpi backlight index   2, val 5
[    3.686147] acpi backlight index   3, val 5
[    3.686172] acpi backlight index   4, val 5
[    3.686197] acpi backlight index   5, val 5
[    3.686223] acpi backlight index   6, val 5
[    3.686248] acpi backlight index   7, val 5
[    3.686273] acpi backlight index   8, val 6
[    3.686332] acpi backlight index   9, val 7
[    3.686356] acpi backlight index  10, val 8
[    3.686380] acpi backlight index  11, val 9
etc.

Notice that brightness values 0-5 are all mapped to 5. This means that
if userspace writes any value between 0 and 5 to the brightness sysfs attribute
and then reads it, it will always return 0, which is somewhat unexpected.

This is a problem for ie gnome-settings-daemon, which uses read-modify-write
logic when the users presses the brightness up or down keys. This is done
this way to take brightness changes from other sources into account.

On this specific laptop what happens once the brightness has been set to 0,
is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press
again reads 0, so things get stuck at the lowest brightness setting.

Filtering out the duplicate table entries, makes any write to brightness
read back as the written value as one would expect, fixing this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If CONFIG_PM_SLEEP=n:

drivers/mfd/sec-core.c:349: warning: ‘sec_pmic_suspend’ defined but not used
drivers/mfd/sec-core.c:371: warning: ‘sec_pmic_resume’ defined but not used
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

If CONFIG_PM_SLEEP=n:

drivers/mfd/max14577.c:177: warning: ‘max14577_suspend’ defined but not used
drivers/mfd/max14577.c:200: warning: ‘max14577_resume’ defined but not used
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

If we compile the TPS65217 for a 64bit architecture we receive the following
warnings:

drivers/mfd/tps65217.c: In function ‘tps65217_probe’:
drivers/mfd/tps65217.c:173:13:
  warning: cast from pointer to integer of different size
   chip_id = (unsigned int)match->data;
             ^
Signed-off-by: NLee Jones <lee.jones@linaro.org>