This adds tracepoints to musb register read/write wrappers to get
trace log for register access.

The default tacepoint log prefix here would be musb_readX/writeX(),
which is not much helpful. So this patch let the tracepoints use
__buildin_return_address(0) to print the caller funciton name to
provide more context of the register access.
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

musb core already exports the register read/write wrappers, so clean up
the duplication in dsps glue.
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Switch dev_dbg() to tracepoint debug musb_dbg().
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

To avoid printk() overhead while debugging, this patch implements the
foundation of tracepoints logging for musb driver to make debug
easier.
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

BugLink: http://bugs.launchpad.net/bugs/1498667

As reported in BugLink, this device has an issue with Linux Power
Management so adding a quirk.  This quirk was reccomended by Alan Stern:

http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05590.htmlSigned-off-by: NJoseph Salisbury <joseph.salisbury@canonical.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes an issue that the extcon_set_cable_state_() is possible
to cause "BUG: scheduling while atomic" because this driver calls
extcon_set_cable_state_() in the interrupt handler and mutex_lock()
is possible to be called by like the following call trace.
So, this patch adds a workqueue function to resolve this issue.

[    9.706504] BUG: scheduling while atomic: systemd-journal/25893/0x00010303
[    9.714569] Modules linked in:
[    9.717629] CPU: 0 PID: 25893 Comm: systemd-journal Not tainted 4.7.0-rc4+ #86
[    9.724844] Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
[    9.731624] Call trace:
[    9.734077] [<ffff0000080889f0>] dump_backtrace+0x0/0x1a8
[    9.739470] [<ffff000008088bac>] show_stack+0x14/0x20
[    9.744520] [<ffff000008348ab4>] dump_stack+0x94/0xb8
[    9.749568] [<ffff0000080da18c>] __schedule_bug+0x44/0x58
[    9.754966] [<ffff0000087c6394>] __schedule+0x4e4/0x598
[    9.760185] [<ffff0000087c6484>] schedule+0x3c/0xa8
[    9.765057] [<ffff0000087c6928>] schedule_preempt_disabled+0x20/0x38
[    9.771408] [<ffff0000080f20dc>] mutex_optimistic_spin+0x18c/0x1d0
[    9.777583] [<ffff0000087c7ef0>] __mutex_lock_slowpath+0x38/0x140
[    9.783669] [<ffff0000087c803c>] mutex_lock+0x44/0x60
[    9.788717] [<ffff00000834ca48>] kobject_uevent_env+0x250/0x500
[    9.794634] [<ffff0000086ae8c0>] extcon_update_state+0x220/0x298
[    9.800634] [<ffff0000086ae9d8>] extcon_set_cable_state_+0x78/0x88
[    9.806812] [<ffff000008376004>] rcar_gen3_device_recognition+0x5c/0xe0
[    9.813420] [<ffff0000083761bc>] rcar_gen3_phy_usb2_irq+0x3c/0x48
[    9.819509] [<ffff0000080fae94>] handle_irq_event_percpu+0x94/0x140
[    9.825769] [<ffff0000080faf88>] handle_irq_event+0x48/0x78
[    9.831334] [<ffff0000080fe620>] handle_fasteoi_irq+0xb8/0x1b0
[    9.837162] [<ffff0000080fa3c4>] generic_handle_irq+0x24/0x38
[    9.842900] [<ffff0000080fa6fc>] __handle_domain_irq+0x5c/0xb8
[    9.848727] [<ffff000008081520>] gic_handle_irq+0x58/0xb0
Reported-by: NSimon Horman <horms@verge.net.au>
Fixes: 2b38543c ("phy: rcar-gen3-usb2: add extcon support")
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>

If devm_add_action() fails we are explicitly calling the cleanup to free
the resources allocated.  Lets use the helper devm_add_action_or_reset()
and return directly in case of error, as we know that the cleanup function
has been already called by the helper if there was any error.
Signed-off-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>

The A31 companion pmic (axp221) does not generate vbus change interrupts
when the board is driving vbus, so we must poll when using the pmic for
vbus-det _and_ we're driving vbus.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>

kzalloc will issue its own error message including a dump_stack()
so remote the site specific message.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>

kzalloc will issue its own error message including a dump_stack()
so remote the site specific message.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>

The usb-phy is fully enclosed in the general register files (GRF).
Therefore as seen from the device-tree it shouldn't be a separate
platform-device but instead a sub-device of the GRF - using the
simply-mfd mechanism.

As the usb-phy is part of the kernel for some releases now, we keep
the old (and now deprecated) binding for compatibility purposes.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>

This is a new phy driver for the SoC USB controllers on the TI DA8xx
family of microcontrollers. The USB 1.1 PHY is just a simple on/off.
The USB 2.0 PHY also allows overriding the VBUS and ID pins.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>

The initial use for this is for PHYs that have a mode related to USB OTG.
There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting
in the USB PHY to override OTG VBUS and ID signals.

Of course, the enum can be expaned in the future to include modes for
other types of PHYs as well.
Suggested-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NDavid Lechner <david@lechnology.com>

No functional change. Rename "enum phy_mode" to
"enum xgene_phy_mode" in xgene phy driver in
preparation for adding set_mode callback in
phy core.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: NLoc Ho <lho@apm.com>

Looks like we lost all changes related to
commit 9522def4 ("usb: dwc3: core: cleanup IRQ resources") in host.c
when Felipe's next branch was merged into Greg's next branch.

Fixes 215db948 ("Merge tag 'usb-for-v4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next")
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

gcc warns about what first looks like a reference to an uninitialized
variable:

drivers/usb/host/xhci-ring.c: In function 'handle_cmd_completion':
drivers/usb/host/xhci-ring.c:753:4: error: 'ep_ring' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    xhci_unmap_td_bounce_buffer(xhci, ep_ring, cur_td);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/usb/host/xhci-ring.c:647:20: note: 'ep_ring' was declared here
  struct xhci_ring *ep_ring;
                    ^~~~~~~

It's clear to see that the list_empty() check means it can never be
uninitialized, however it still looks wrong:

When ep->cancelled_td_list contains more than one entry, the
ep_ring variable will point to the ring that was retrieved
from the last urb, and we have to look it up again in the
second loop instead, which fixes the behavior and gets rid of the
warning too.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: f9c589e1 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We're making all reset line users specify whether their lines are
shared with other IP or they operate them exclusively.  In this case
the line is exclusively used only by this IP, so use the *_exclusive()
API accordingly.
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

We're making all reset line users specify whether their lines are
shared with other IP or they operate them exclusively.  In this case
the line is exclusively used only by this IP, so use the *_exclusive()
API accordingly.
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

On the STiH410 B2120 development board the MiPHY28lp shares its reset
line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
(DRD).  New functionality in the reset subsystems forces consumers to
be explicit when requesting shared/exclusive reset lines.
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The omitted parenthesis prevents the addition operation when
acpi_penalize_isa_irq function is called.

Fixes: 103544d8 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add the missing unlock before return from function i915_ppgtt_info()
in the error handling case.

Fixes: 1d2ac403(drm: Protect dev->filelist with its own mutex)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465861320-26221-1-git-send-email-weiyj_lk@163.com
(cherry picked from commit b0212486)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When configuring FPS during probe, assuming a DT node is present for
FPS, the code can run into a problem with the switch statements in
max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely,
in the case of chip->chip_id == MAX77620, it will set
fps_[mix|max]_period but then fall through to the default switch case
and return -EINVAL. Returning this from max77620_config_fps() will
cause probe to fail.
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Reviewed-by: NLaxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Tested-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

On the STiH410 B2120 development board the ports on the Generic PHY
share their reset lines with each other.  New functionality in the
reset subsystems forces consumers to be explicit when requesting
shared/exclusive reset lines.
Signed-off-by: NLee Jones <lee.jones@linaro.org>

On the STiH410 B2120 development board the MiPHY28lp shares its reset
line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
(DRD).  New functionality in the reset subsystems forces consumers to
be explicit when requesting shared/exclusive reset lines.
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

On the STiH410 B2120 development board the ST EHCI IP shares its reset
line with the OHCI IP.  New functionality in the reset subsystems forces
consumers to be explicit when requesting shared/exclusive reset lines.
Acked-by: NPeter Griffin <peter.griffin@linaro.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

On the STiH410 B2120 development board the ST EHCI IP shares its reset
line with the OHCI IP.  New functionality in the reset subsystems forces
consumers to be explicit when requesting shared/exclusive reset lines.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Per JEDEC Annex L Release 3 the SPD data is:

Bits 9~5 00 000 = Function Undefined
         00 001 = Byte addressable energy backed
         00 010 = Block addressed
         00 011 = Byte addressable, no energy backed
         All other codes reserved
Bits 4~0 0 0000 = Proprietary interface
         0 0001 = Standard interface 1
         All other codes reserved; see Definitions of Functions

...and per the ACPI 6.1 spec:

    byte0: Bits 4~0 (0 or 1)
    byte1: Bits 9~5 (1, 2, or 3)

...so a format interface code displayed as 0x301 should be stored in the
nfit as (0x1, 0x3), little-endian.

Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Robert Elliott <elliott@hpe.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=121161
Fixes: 30ec5fd4 ("nfit: fix format interface code byte order per ACPI6.1")
Fixes: 5ad9a7fd ("acpi/nfit: Update nfit driver to comply with ACPI 6.1")
Reported-by: NKristin Jacque <kristin.jacque@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

SD4 regulator is not registered with regulator core
framework in probe as there is no support in MAX77620 PMIC,
removing SD4 entry from MAX77620 regulator information list
and checking for valid regulator information data before
configuring FPS source and FPS power up/down period to avoid
NULL pointer exception if regulator not registered with core.
Signed-off-by: NVenkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

workaround issue that when uvd dpm disabled,
uvd clock remain high on polaris10. Manually turn
off the clocks.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NKen Wang <Qingqing.Wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This is a temporary workaround for early boards.
Signed-off-by: NKen Wang <Qingqing.Wang@amd.com>
Reviewed-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

1. Populate correct value of VDDCI voltage for SMC SAMU, VCE,
   and UVD levels depending on whether VDDCi control is SVI2 or GPIO.
2. Populate SMC ACPI minimum voltage using VBIOS boot SCLK and MCLK

When static voltage is configured as VDDCI, driver still tries to program
a voltage for MM minVoltage using VDDC-VDDCI delta requirement.
minVoltage should be set as boot up voltage.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

SPQ doorbell is currently protected with the compilation barrier. Under the
stress scenarios, we may get into a state where (due to the weak ordering)
several ramrod doorbells were written to the BAR with an out-of-order
producer values. Need to change the barrier type to a write barrier to make
sure that the write buffer is flushed after each doorbell.
Signed-off-by: NSudarsana Reddy Kalluru <sudarsana.kalluru@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I've got a bug report about an e1000e interface, where a VLAN interface is
set up on top of it:

$ ip link add link ens1f0 name ens1f0.99 type vlan id 99
$ ip link set ens1f0 up
$ ip link set ens1f0.99 up
$ ip addr add 192.168.99.92 dev ens1f0.99

At this point, I can ping another host on vlan 99, ip 192.168.99.91.
However, if I do the following:

$ ethtool -K ens1f0 rxvlan off

Then no traffic passes on ens1f0.99. It comes back if I toggle rxvlan on
again. I'm not sure if this is actually intended behavior, or if there's a
lack of software VLAN stripping fallback, or what, but things continue to
work if I simply don't call e1000e_vlan_strip_disable() if there are
active VLANs (plagiarizing a function from the e1000 driver here) on the
interface.

Also slipped a related-ish fix to the kerneldoc text for
e1000e_vlan_strip_disable here...
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is a static checker warning here "warn: mask and shift to zero"
and the code sets "ring" to zero every time.  From looking at how
QLCNIC_FETCH_RING_ID() is used in qlcnic_83xx_process_rcv_ring() the
qlcnic_83xx_hndl() should be removed.

Fixes: 4be41e92 ('qlcnic: 83xx data path routines')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since we will remove items off the list using list_del() we need
to use a safe version of the list_for_each() macro aptly named
list_for_each_safe().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

TL4 calculation for a given SQ of secondary Qsets is incorrect
and goes out of bounds and also for some SQ's TL4 chosen will
transmit data via a different BGX interface and not same as
primary Qset's interface.

This patch fixes this issue.
Signed-off-by: NSunil Goutham <sgoutham@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Check for SMU RX local/remote faults along with SPU LINK
status. Otherwise at times link is UP at our end but DOWN
at link partner's side. Also due to an issue in BGX it's
rarely seen that initialization doesn't happen properly
and SMU RX reports faults with everything fine at SPU.
This patch tries to reinitialize LMAC to fix it.

Also fixed LMAC disable sequence to properly bring down link.
Signed-off-by: NSunil Goutham <sgoutham@cavium.com>
Signed-off-by: NTao Wang <tao.wang@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Categorize and reorganize ethtool statistics counters by renaming to
"rx_*" and "tx_*" and removing redundant and duplicated counters, this
way they are easier to grasp and more user friendly.
Signed-off-by: NGal Pressman <galp@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Number of PFC counters used to count only number of priorities with PFC
enabled, but each priority has more than one counter, hence the need to
multiply it by the number of PFC counters per priority.

Fixes: cf678570 ('net/mlx5e: Add per priority group to PPort counters')
Signed-off-by: NGal Pressman <galp@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>