dm cache: fix corruption seen when using cache > 2TB

commit ca763d0a53b264a650342cee206512bc92ac7050 upstream.

A rounding bug due to compiler generated temporary being 32bit was found
in remap_to_cache().  A localized cast in remap_to_cache() fixes the
corruption but this preferred fix (changing from uint32_t to sector_t)
eliminates potential for future rounding errors elsewhere.

Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipc/shm: Fix shmat mmap nil-page protection

commit 95e91b831f87ac8e1f8ed50c14d709089b4e01b8 upstream.

The issue is described here, with a nice testcase:

    https://bugzilla.kernel.org/show_bug.cgi?id=192931

The problem is that shmat() calls do_mmap_pgoff() with MAP_FIXED, and
the address rounded down to 0.  For the regular mmap case, the
protection mentioned above is that the kernel gets to generate the
address -- arch_get_unmapped_area() will always check for MAP_FIXED and
return that address.  So by the time we do security_mmap_addr(0) things
get funky for shmat().

The testcase itself shows that while a regular user crashes, root will
not have a problem attaching a nil-page.  There are two possible fixes
to this.  The first, and which this patch does, is to simply allow root
to crash as well -- this is also regular mmap behavior, ie when hacking
up the testcase and adding mmap(...  |MAP_FIXED).  While this approach
is the safer option, the second alternative is to ignore SHM_RND if the
rounded address is 0, thus only having MAP_SHARED flags.  This makes the
behavior of shmat() identical to the mmap() case.  The downside of this
is obviously user visible, but does make sense in that it maintains
semantics after the round-down wrt 0 address and mmap.

Passes shm related ltp tests.

Link: http://lkml.kernel.org/r/1486050195-18629-1-git-send-email-dave@stgolabs.net
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Gareth Evans <gareth.evans@contextis.co.uk>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm: do not access page->mapping directly on page_endio

commit dd8416c47715cf324c9a16f13273f9fda87acfed upstream.

With rw_page, page_endio is used for completing IO on a page and it
propagates write error to the address space if the IO fails.  The
problem is it accesses page->mapping directly which might be okay for
file-backed pages but it shouldn't for anonymous page.  Otherwise, it
can corrupt one of field from anon_vma under us and system goes panic
randomly.

swap_writepage
  bdev_writepage
    ops->rw_page

I encountered the BUG during developing new zram feature and it was
really hard to figure it out because it made random crash, somtime
mmap_sem lockdep, sometime other places where places never related to
zram/zsmalloc, and not reproducible with some configuration.

When I consider how that bug is subtle and people do fast-swap test with
brd, it's worth to add stable mark, I think.

Fixes: dd6bd0d9c7db ("swap: use bdev_read_page() / bdev_write_page()")
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm: vmpressure: fix sending wrong events on underflow

commit e1587a4945408faa58d0485002c110eb2454740c upstream.

At the end of a window period, if the reclaimed pages is greater than
scanned, an unsigned underflow can result in a huge pressure value and
thus a critical event.  Reclaimed pages is found to go higher than
scanned because of the addition of reclaimed slab pages to reclaimed in
shrink_node without a corresponding increment to scanned pages.

Minchan Kim mentioned that this can also happen in the case of a THP
page where the scanned is 1 and reclaimed could be 512.

Link: http://lkml.kernel.org/r/1486641577-11685-1-git-send-email-vinmenon@codeaurora.org
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Rik van Riel <riel@redhat.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: Shiraz Hashim <shashim@codeaurora.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm/page_alloc: fix nodes for reclaim in fast path

commit e02dc017c3032dcdce1b993af0db135462e1b4b7 upstream.

When @node_reclaim_node isn't 0, the page allocator tries to reclaim
pages if the amount of free memory in the zones are below the low
watermark.  On Power platform, none of NUMA nodes are scanned for page
reclaim because no nodes match the condition in zone_allows_reclaim().
On Power platform, RECLAIM_DISTANCE is set to 10 which is the distance
of Node-A to Node-A.  So the preferred node even won't be scanned for
page reclaim.

   __alloc_pages_nodemask()
   get_page_from_freelist()
      zone_allows_reclaim()

Anton proposed the test code as below:

   # cat alloc.c
      :
   int main(int argc, char *argv[])
   {
void *p;
unsigned long size;
unsigned long start, end;

start = time(NULL);
size = strtoul(argv[1], NULL, 0);
printf("To allocate %ldGB memory\n", size);

size <<= 30;
p = malloc(size);
assert(p);
memset(p, 0, size);

end = time(NULL);
printf("Used time: %ld seconds\n", end - start);
sleep(3600);
return 0;
   }

The system I use for testing has two NUMA nodes.  Both have 128GB
memory.  In below scnario, the page caches on node#0 should be reclaimed
when it encounters pressure to accommodate request of allocation.

   # echo 2 > /proc/sys/vm/zone_reclaim_mode; \
     sync; \
     echo 3 > /proc/sys/vm/drop_caches; \
   # taskset -c 0 cat file.32G > /dev/null; \
     grep FilePages /sys/devices/system/node/node0/meminfo
     Node 0 FilePages:       33619712 kB
   # taskset -c 0 ./alloc 128
   # grep FilePages /sys/devices/system/node/node0/meminfo
     Node 0 FilePages:       33619840 kB
   # grep MemFree /sys/devices/system/node/node0/meminfo
     Node 0 MemFree:          186816 kB

With the patch applied, the pagecache on node-0 is reclaimed when its
free memory is running out.  It's the expected behaviour.

   # echo 2 > /proc/sys/vm/zone_reclaim_mode; \
     sync; \
     echo 3 > /proc/sys/vm/drop_caches
   # taskset -c 0 cat file.32G > /dev/null; \
     grep FilePages /sys/devices/system/node/node0/meminfo
     Node 0 FilePages:       33605568 kB
   # taskset -c 0 ./alloc 128
   # grep FilePages /sys/devices/system/node/node0/meminfo
     Node 0 FilePages:        1379520 kB
   # grep MemFree /sys/devices/system/node/node0/meminfo
     Node 0 MemFree:           317120 kB

Fixes: 5f7a75acdb24 ("mm: page_alloc: do not cache reclaim distances")
Link: http://lkml.kernel.org/r/1486532455-29613-1-git-send-email-gwshan@linux.vnet.ibm.com
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iommu/vt-d: Tylersburg isoch identity map check is done too late.

commit 21e722c4c8377b5bc82ad058fed12165af739c1b upstream.

The check to set identity map for tylersburg is done too late. It needs
to be done before the check for identity_map domain is done.

To: Joerg Roedel <joro@8bytes.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: iommu@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: Ashok Raj <ashok.raj@intel.com>
Fixes: 86080ccc22 ("iommu/vt-d: Allocate si_domain in init_dmars()")
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Reported-by: Yunhong Jiang <yunhong.jiang@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

commit aaa59306b0b7e0ca4ba92cc04c5db101cbb1c096 upstream.

Some of the macros are incorrect with wrong bit-shifts resulting in picking
the incorrect invalidation granularity. Incorrect Source-ID in extended
devtlb invalidation caused device side errors.

To: Joerg Roedel <joro@8bytes.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: iommu@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: CQ Tang <cq.tang@intel.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Fixes: 2f26e0a9 ("iommu/vt-d: Add basic SVM PASID support")
Signed-off-by: CQ Tang <cq.tang@intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Tested-by: CQ Tang <cq.tang@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: Fix regulator_summary for deviceless consumers

commit e42a46b6f52473661ad192f76a128a68fe301df4 upstream.

It is allowed to call regulator_get with a NULL dev argument
(_regulator_get explicitly checks for it) but this causes an error later
when printing /sys/kernel/debug/regulator_summary.

Fix this by explicitly handling "deviceless" consumers in the debugfs code.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: rtl: fix possible NULL pointer dereference

commit 6e017006022abfea5d2466cad936065f45763ad1 upstream.

gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with
a destination argument that an earlier function call may have set to NULL:

staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr':
staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where non-null expected [-Wnonnull]
staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr':
staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null expected [-Wnonnull]

I'm fixing this by adding a NULL pointer check and returning failure
from the function, which is hopefully already handled properly.

This seems to date back to when the drivers were originally added,
so backporting the fix to stable seems appropriate. There are other
related realtek drivers in the kernel, but none of them contain a
function with a similar name or produce this warning.

Fixes: 1cc18a22b96b ("staging: r8188eu: Add files for new driver - part 5")
Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - Fix micmute hotkey problem for a lenovo AIO machine

commit 29693efcea0f38cf40d0055d2401490a4f9bf8be upstream.

On this machine, the micmute button is connected to Line2 of the
codec and the micmute led is connected to GPIO2 of the codec.

After applying this quirk, both hotkey and led work well.

Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - Add subwoofer support for Dell Inspiron 17 7000 Gaming

commit 493de342748cc6f52938096f5480cf291da58a0b upstream.

Dell Inspiron 17 7000 Gaming laptop needs a similar quirk like
Inspiron 7599 to support its subwoofer speaker.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194191
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: seq: Fix link corruption by event error handling

commit f3ac9f737603da80c2da3e84b89e74429836bb6d upstream.

The sequencer FIFO management has a bug that may lead to a corruption
(shortage) of the cell linked list.  When a sequencer client faces an
error at the event delivery, it tries to put back the dequeued cell.
When the first queue was put back, this forgot the tail pointer
tracking, and the link will be screwed up.

Although there is no memory corruption, the sequencer client may stall
forever at exit while flushing the pending FIFO cells in
snd_seq_pool_done(), as spotted by syzkaller.

This patch addresses the missing tail pointer tracking at
snd_seq_fifo_cell_putback().  Also the patch makes sure to clear the
cell->enxt pointer at snd_seq_fifo_event_in() for avoiding a similar
mess-up of the FIFO linked list.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: ctxfi: Fallback DMA mask to 32bit

commit 15c75b09f8d190f89ab4db463b87d411ca349dfe upstream.

Currently ctxfi driver tries to set only the 64bit DMA mask on 64bit
architectures, and bails out if it fails.  This causes a problem on
some platforms since the 64bit DMA isn't always guaranteed.  We should
fall back to the default 32bit DMA when 64bit DMA fails.

Fixes: 6d74b86d3c0f ("ALSA: ctxfi - Allow 64bit DMA")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: timer: Reject user params with too small ticks

commit 71321eb3f2d0df4e6c327e0b936eec4458a12054 upstream.

When a user sets a too small ticks with a fine-grained timer like
hrtimer, the kernel tries to fire up the timer irq too frequently.
This may lead to the condensed locks, eventually the kernel spinlock
lockup with warnings.

For avoiding such a situation, we define a lower limit of the
resolution, namely 1ms.  When the user passes a too small tick value
that results in less than that, the kernel returns -EINVAL now.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - fix Lewisburg audio issue

commit e7480b34ad1ab84a63540b2c884cb92c0764ab74 upstream.

Like for Sunrise Point, the total stream number of Lewisburg's
input and output stream exceeds 15 (GCAP is 0x9701), which will
cause some streams do not work because of the overflow on
SDxCTL.STRM field if using the legacy stream tag allocation method.

Fixes: 5cf92c8b3dc5 ("ALSA: hda - Add Intel Lewisburg device IDs Audio")
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek - Cannot adjust speaker's volume on a Dell AIO

commit 9f1bc2c4c58fcb2d86e0e26437dc8f3a18ac3276 upstream.

The issue is the same as "dd9aa335c880 ALSA: hda/realtek - Can't adjust
speaker's volume on a Dell AIO", the output requires to connect to a node
with Amp-out capability.

Applying the same fixup "ALC298_FIXUP_SPK_VOLUME" can fix the issue.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: at91: Enable DMA on sama5d2_xplained console

commit 78162d48466d23c45a784034630c5928af631e3d upstream.

Enable DMA on uart1 to get a more reliable console.

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: at91: Enable DMA on sama5d4_xplained console

commit ef8d02d4a2c36f7a93e74c95a9c419353b310117 upstream.

Enable DMA on usart3 to get a more reliable console. This is especially
useful for automation and kernelci were a kernel with PROVE_LOCKING enabled
is quite susceptible to character loss, resulting in tests failure.

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: at91: define LPDDR types

commit e3f0a4017c2143b4b813df6a93e8cf79e3f76936 upstream.

The Atmel MPDDR controller support LPDDR2 and LPDDR3 memories, add their
types.

Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: fix dm1105.c build error

commit e3bb3cddd177550d63a3e4909cf1a7782f13414d upstream.

Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and
CONFIG_DVB_DM1105=y.

drivers/built-in.o: In function `dm1105_probe':
dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

uvcvideo: Fix a wrong macro

commit 17c341ec0115837a610b2da15e32546e26068234 upstream.

Don't mix up UVC_BUF_STATE_* and VB2_BUF_STATE_* codes.

Fixes: 6998b6fb4b1c ("[media] uvcvideo: Use videobuf2-vmalloc")
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

am437x-vpfe: always assign bpp variable

commit 6ebf75774f823ddbdbd10921006989d4df222f4a upstream.

In vpfe_s_fmt(), when the sensor format and the requested format were
the same, bpp was assigned to vpfe->bpp without being initialized first.

Grab the bpp value that is currently used by using __vpfe_get_format()
instead of its wrapper, vpfe_try_fmt().

This use of uninitialized variable has been found by compiling the
kernel with clang.

Fixes: 417d2e507edc ("[media] media: platform: add VPFE capture driver
support for AM437X")

Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Handle microMIPS jumps in the same way as MIPS32/MIPS64 jumps

commit 096a0de427ea333f56f0ee00328cff2a2731bcf1 upstream.

is_jump_ins() checks for plain jump ("j") instructions since commit
e7438c4b893e ("MIPS: Fix sibling call handling in get_frame_info") but
that commit didn't make the same change to the microMIPS code, leaving
it inconsistent with the MIPS32/MIPS64 code. Handle the microMIPS
encoding of the jump instruction too such that it behaves consistently.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: e7438c4b893e ("MIPS: Fix sibling call handling in get_frame_info")
Cc: Tony Wu <tung7970@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14533/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Calculate microMIPS ra properly when unwinding the stack

commit bb9bc4689b9c635714fbcd5d335bad9934a7ebfc upstream.

get_frame_info() calculates the offset of the return address within a
stack frame simply by dividing a the bottom 16 bits of the instruction,
treated as a signed integer, by the size of a long. Whilst this works
for MIPS32 & MIPS64 ISAs where the sw or sd instructions are used, it's
incorrect for microMIPS where encodings differ. The result is that we
typically completely fail to unwind the stack on microMIPS.

Fix this by adjusting is_ra_save_ins() to calculate the return address
offset, and take into account the various different encodings there in
the same place as we consider whether an instruction is storing the
ra/$31 register.

With this we are now able to unwind the stack for kernels targetting the
microMIPS ISA, for example we can produce:

    Call Trace:
    [<80109e1f>] show_stack+0x63/0x7c
    [<8011ea17>] __warn+0x9b/0xac
    [<8011ea45>] warn_slowpath_fmt+0x1d/0x20
    [<8013fe53>] register_console+0x43/0x314
    [<8067c58d>] of_setup_earlycon+0x1dd/0x1ec
    [<8067f63f>] early_init_dt_scan_chosen_stdout+0xe7/0xf8
    [<8066c115>] do_early_param+0x75/0xac
    [<801302f9>] parse_args+0x1dd/0x308
    [<8066c459>] parse_early_options+0x25/0x28
    [<8066c48b>] parse_early_param+0x2f/0x38
    [<8066e8cf>] setup_arch+0x113/0x488
    [<8066c4f3>] start_kernel+0x57/0x328
    ---[ end trace 0000000000000000 ]---

Whereas previously we only produced:

    Call Trace:
    [<80109e1f>] show_stack+0x63/0x7c
    ---[ end trace 0000000000000000 ]---

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14532/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Fix is_jump_ins() handling of 16b microMIPS instructions

commit 67c75057709a6d85c681c78b9b2f9b71191f01a2 upstream.

is_jump_ins() checks 16b instruction fields without verifying that the
instruction is indeed 16b, as is done by is_ra_save_ins() &
is_sp_move_ins(). Add the appropriate check.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14531/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Fix get_frame_info() handling of microMIPS function size

commit b6c7a324df37bf05ef7a2c1580683cf10d082d97 upstream.

get_frame_info() is meant to iterate over up to the first 128
instructions within a function, but for microMIPS kernels it will not
reach that many instructions unless the function is 512 bytes long since
we calculate the maximum number of instructions to check by dividing the
function length by the 4 byte size of a union mips_instruction. In
microMIPS kernels this won't do since instructions are variable length.

Fix this by instead checking whether the pointer to the current
instruction has reached the end of the function, and use max_insns as a
simple constant to check the number of iterations against.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14530/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Prevent unaligned accesses during stack unwinding

commit a3552dace7d1d0cabf573e88fc3025cb90c4a601 upstream.

During stack unwinding we call a number of functions to determine what
type of instruction we're looking at. The union mips_instruction pointer
provided to them may be pointing at a 2 byte, but not 4 byte, aligned
address & we thus cannot directly access the 4 byte wide members of the
union mips_instruction. To avoid this is_ra_save_ins() copies the
required half-words of the microMIPS instruction to a correctly aligned
union mips_instruction on the stack, which it can then access safely.
The is_jump_ins() & is_sp_move_ins() functions do not correctly perform
this temporary copy, and instead attempt to directly dereference 4 byte
fields which may be misaligned and lead to an address exception.

Fix this by copying the instruction halfwords to a temporary union
mips_instruction in get_frame_info() such that we can provide a 4 byte
aligned union mips_instruction to the is_*_ins() functions and they do
not need to deal with misalignment themselves.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14529/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Clear ISA bit correctly in get_frame_info()

commit ccaf7caf2c73c6db920772bf08bf1d47b2170634 upstream.

get_frame_info() can be called in microMIPS kernels with the ISA bit
already clear. For example this happens when unwind_stack_by_address()
is called because we begin with a PC that has the ISA bit set & subtract
the (odd) offset from the preceding symbol (which does not have the ISA
bit set). Since get_frame_info() unconditionally subtracts 1 from the PC
in microMIPS kernels it incorrectly misaligns the address it then
attempts to access code at, leading to an address error exception.

Fix this by using msk_isa16_mode() to clear the ISA bit, which allows
get_frame_info() to function regardless of whether it is provided with a
PC that has the ISA bit set or not.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14528/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Lantiq: Keep ethernet enabled during boot

commit 774f0c6419bb8f9d83901d33582c7fe3ba6a6cb3 upstream.

Disabling ethernet during reboot (only to enable it again when the
ethernet driver attaches) can put the chip into a faulty state where it
corrupts the header of all incoming packets.

This happens if packets arrive during the time window where the core is
disabled, and it can be easily reproduced by rebooting while sending a
flood ping to the broadcast address.

Fixes: 95135bfa7ead ("MIPS: Lantiq: Deactivate most of the devices by default")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Acked-by: John Crispin <john@phrozen.org>
Cc: hauke.mehrtens@lantiq.com
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15078/
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: OCTEON: Fix copy_from_user fault handling for large buffers

commit 884b426917e4b3c85f33b382c792a94305dfdd62 upstream.

If copy_from_user is called with a large buffer (>= 128 bytes) and the
userspace buffer refers partially to unreadable memory, then it is
possible for Octeon's copy_from_user to report the wrong number of bytes
have been copied. In the case where the buffer size is an exact multiple
of 128 and the fault occurs in the last 64 bytes, copy_from_user will
report that all the bytes were copied successfully but leave some
garbage in the destination buffer.

The bug is in the main __copy_user_common loop in octeon-memcpy.S where
in the middle of the loop, src and dst are incremented by 128 bytes. The
l_exc_copy fault handler is used after this but that assumes that
"src < THREAD_BUADDR($28)". This is not the case if src has already been
incremented.

Fix by adding an extra fault handler which rewinds the src and dst
pointers 128 bytes before falling though to l_exc_copy.

Thanks to the pwritev test from the strace test suite for originally
highlighting this bug!

Fixes: 5b3b16880f40 ("MIPS: Add Cavium OCTEON processor support ...")
Signed-off-by: James Cowgill <James.Cowgill@imgtec.com>
Acked-by: David Daney <david.daney@cavium.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14978/
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: BCM47XX: Fix button inversion for Asus WL-500W

commit bdfdaf1a016ef09cb941f2edad485a713510b8d5 upstream.

The Asus WL-500W buttons are active high, but the software treats them
as active low. Fix the inverted logic.

Fixes: 3be972556fa1 ("MIPS: BCM47XX: Import buttons database from OpenWrt")
Signed-off-by: Mirko Parthey <mirko.parthey@web.de>
Acked-by: Rafał Miłecki <rafal@milecki.pl>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15295/
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Fix special case in 64 bit IP checksumming.

commit 66fd848cadaa6be974a8c780fbeb328f0af4d3bd upstream.

For certain arguments such as saddr = 0xc0a8fd60, daddr = 0xc0a8fda1,
len = 80, proto = 17, sum = 0x7eae049d there will be a carry when
folding the intermediate 64 bit checksum to 32 bit but the code doesn't
add the carry back to the one's complement sum, thus an incorrect result
will be generated.

Reported-by: Mark Zhang <bomb.zhang@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

samples: move mic/mpssd example code from Documentation

commit 6bee835dd54e279f3d3ae2eca92a9c394b4fd028 upstream.

Move mic/mpssd examples to samples and remove it from Documentation
Makefile. Create a new Makefile to build mic/mpssd. It can be built
from top level directory or from mic/mpssd directory:

Run make -C samples/mic/mpssd or cd samples/mic/mpssd; make

Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
[backported to 4.4-stable as this code is broken on newer versions of
 gcc and we don't want to break the build for a Documentation sample.
 - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: wireless: rockchip_wlan: update for ap6xxx wifi firmware

bcmdhd driver support ko module or compile into kernel

Change-Id: I260c9d3c3da0a9e249a4ee3883ed3efe03964ddf
Signed-off-by: Xu Xuehui <xxh@rock-chips.com>

linux: mfd: rk808: fix up the RK818_NUM_REGULATORS

Change-Id: I049286ec7afcaa66ca88458f51a3e0d516121001
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

FROMLIST: drm/bridge: analogix_dp: Don't read EDID if panel present

If there's a panel connected to the analogix_dp bridge, rely on
the panel driver for modes, rather than reading EDID *and* calling
get_modes() on the panel.

This allows panels with a valid EDID to read it in the panel driver
(e.g. simple_panel), and panels with invalid EDID to homebrew modes
in their get_modes implementation.

BUG=chrome-os-partner:53565
TEST=Boot device and confirm the modes returned are from panel driver
     instead of EDID

[from https://patchwork.freedesktop.org/patch/107115/]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374959
Commit-Ready: Chris Zhong <zyw@rock-chips.com>
Tested-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Change-Id: Ie07dd33e3c121215bf24394cfcb3fff8c7c746a5
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

arm64: rockchip_defconfig: enable CONFIG_BT_RTKBTUSB

Change-Id: I571f3c53cb63a0f5f4d11c2e3dd128d828815b47
Signed-off-by: xiaoyao <xiaoyao@rock-chips.com>

net: wireless: rockchip: add rtl8822be pcie wifi driver

Change-Id: Ibdc9a9272bf5221b56e2c63b59ffcba41674994c
Signed-off-by: xiaoyao <xiaoyao@rock-chips.com>

arm64: rockchip_defconfig: enable CONFIG_WIFI_LOAD_DRIVER_WHEN_KERNEL_BOOTUP

Change-Id: Idd64d6b137dc4bdabfd553bd6912d75a405b6485
Signed-off-by: Xu Xuehui <xxh@rock-chips.com>

iommu/rockchip: don't do power domain enable on probe

Change-Id: I1484cbe6f7aa4fe358a3223de62a19aabee29d5c
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

ARM64: dts: rk3368-android: assigned aclk_vop to 400Mhz

Change-Id: Ie70934cb7046aa96a94e14b251d11e87a98b1512
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

ARM64: dts: rk3368-android: set firmware_class.path=/system/vendor/firmware

It's required by gpu driver, which will load firmware through
/system/vendor/firmware.

If android finds another way to fix it, then can be reverted.

Change-Id: I2fede28f022f10c2e16f68b21159a638a10a53ec
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

staging: ion: add api to set/get platform device

Change-Id: Ic251497b173608e1f98bf68fbf2b54b75f89c143
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

Revert "arm64/dma-mapping: __generic_dma_ops always call swiotlb_dma_ops"

This reverts commit 3e89f7de9a3abe9cff127e161d4e11699554cb76.

Change-Id: I4cf45807f91ab3021b6593f171c1f2573e1ea7f2
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

ARM64: dts: rk3399 box: enable hdmi_dp_sound

Change-Id: I04bdec75510b3e47a62a5093fdbd6ec66926e282
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

ARM64: dts: rk3399-android: add hdmi-dp drm audio

this patch register hdmi and dp as one sound card, and compatible
single hdmi audio, single dp audio or both.

Change-Id: I840e6c13f1a0c765a3a9235eb0a798011fc3bf06
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

ARM64: configs: rockchip: enable SND_SOC_ROCKCHIP_HDMI_DP

Change-Id: Icce0802191f2f92913ffc637c50d849bfa79859a
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

drm/rockchip: cdn-dp: return zero when dp is inactive

Change-Id: I741b8ac140014c7f046f59e371ed3ddb245468a2
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

ASoC: rockchip: add machine driver for built-in hdmi and dp

this patch is used for rockchip built-in HDMI and DP audio output which are
wired to the same i2s line. so we use a DAI link CPU to multicodecs.

Change-Id: Ie8d1ede201a4d4b4cd11c8c05cd1f6177d844957
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

UPSTREAM: ASoC: soc-core: snd_soc_get_dai_name() become non static

snd_soc_get_dai_name() is used from snd_soc_of_get_dai_name(),
and it is assuming that DT is using "sound-dai" / "#sound-dai-cells".
But graph base DT is using "remote-endpoint". This patch makes
snd_soc_get_dai_name() non static for graph support.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
(cherry picked from commit 1ad8ec535b997ed36c0f32c2616206725258dd30)

Change-Id: If99dcbfa722f09e3238cfafb5dc2803b6636a2e0

arm64: dts: rockchip: amend usb-otg related nodes for rk3368-tb

This adds move some common properties of usb-otg from dts to dtsi.

Change-Id: I84355433b5ca63cc0b763d66dcdbb38897635418
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>

ARM: dts: rockchip: use hdmi-ddc for ddc bus in rk3288

Using the builtin I2C controller in dw_hdmi is better than using the
normal RK3288 I2C controller(I2C5).

Test: work normally when switch mode between 4K@60hz|4K@30hz|1080P..
Change-Id: Ifb4b72ca5649efb0cc3055f2db34ebbcc2377c4c
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

arm64: dts: rockchip: use hdmi-ddc for ddc bus in rk3399

Using the builtin I2C controller in dw_hdmi is better than using the
normal RK3399 I2C controller(I2C3).

Change-Id: I6a2de7221263e8564f7cca56ea5c52e1a133c138
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

FROMLIST: drm/bridge: dw_hdmi: support i2c extended read mode

"I2C Master Interface Extended Read Mode" implements a segment
pointer-based read operation using the Special Register configuration.

This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned
"The current implementation does not support "I2C Master Interface
Extended Read Mode" to read data addressed by non-zero segment
pointer, this means that if EDID has more than 1 extension blocks"

With this patch,dw-hdmi can read EDID data with 1/2/4 blocks.

(am from https://patchwork.kernel.org/patch/9586343/)

BUG=chrome-os-partner:59768
TEST=fievel can read 1/2/4 blocks EDID data

Change-Id: I086e6ea63ec69c0532be445b958ce253a7f1f3cc
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/442308
Reviewed-by: Douglas Anderson <dianders@chromium.org>

video: rockchip: vop: add ourput color bt601, bt709, bt2020

Change-Id: I0b679244817f1a524d6f834ade32dce1666a6352
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>
(cherry picked from commit b76f11e6652a825fd4cb7798ec3fe06c60587338)

arm64: dts: rk3399: sapphire-excavator: enabled hdmi sound

Change-Id: If95f0b885aa3afdbaa985b4b39628502075be90e
Signed-off-by: wlq <wlq@rock-chips.com>

clk: rockchip: rk3368: add CLK_IGNORE_UNUSED flag for mcu clk

Change-Id: I27856c9523ac3bffd4b509f016a659a1e3094b41
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: pwm: Use pwm_get/set_xxx() helpers where appropriate

Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx
field. Doing that will ease adaptation of the PWM framework to support
atomic update.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 4b58896f72176b781816a9e14dcea5f755b19b5c)

Change-Id: Ic6bdaf2017bb292ef920604fba86805999cebf0c
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

arm64: dts: rockchip: sync pmugrf with upstream for rk3399

Change-Id: I0b023824265418c72413e6702fbc5592eba0dc4e
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

arm64: dts: rockchip: rename ethernet node name for rk3399

Same as upstream.

Change-Id: I737f7974d01a22abc697483956db795e7e151fe0
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

UPSTREAM: arm64: dts: rockchip: add rk3399 thermal_zones phandle

We're going to need to amend this table in board files.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 647cea2e68420fa73efb97c908cdf0c852c22cec)

Change-Id: Ife7affa44554622b1b35ad6756cef78d22c69a3a
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

arm64: dts: rockchip: reorder some nodes for rk3399

keep order as upstream.

Change-Id: I52e0dfe97f0d12c550603675085a66346529794d
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

ARM64: dts: rockchip: rk3399: change the pll init freq

set npll init freq 600M
set gpll init freq 800M

Change-Id: I110cc4b4051504dd875712bce9e473f74d8578b4
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

pwm: rockchip: Fix the warning for rockchip_linux_defconfig

This patch fix the following warning:
drivers/pwm/pwm-rockchip.c:176:6: warning: unused variable 'ret' [-Wunused-variable]

Change-Id: I9ac08ad08fdefee5b875d36592936b07f032586c
Signed-off-by: David Wu <david.wu@rock-chips.com>

net: wireless: rockchip_wlan: update realtek wifi support

support wifi driver work as ko module or compile into kernel

1. wifi driver work as ko module, configs show as below:

CONFIG_WIFI_LOAD_DRIVER_WHEN_KERNEL_BOOTUP=n
CONFIG_RTL8188EU = m and CONFIG_RTL8188FU = m

2. wifi driver compile into kernel, configs show as below:
ps: Only one Realtek driver can be compiled into the kernel
CONFIG_WIFI_LOAD_DRIVER_WHEN_KERNEL_BOOTUP=y
CONFIG_RTL8188EU = y or CONFIG_RTL8188FU = y

Change-Id: I40e33a6f27597f9f90d9987d189b74fb637c40c1
Signed-off-by: Xu Xuehui <xxh@rock-chips.com>

arm64: dts: rockchip: rk3399: set ir irq handle on cpu1

Change-Id: I89f75184af810a050f6ca09daeba17774af4465e
Signed-off-by: Huang zhibao <hzb@rock-chips.com>

drm/rockchip: vop: fix background color on yuv domain

On yuv domain, background need use 10bit yuv format.

Change-Id: I02fe3894ac12b509e22c0d90977bcb7e4535c16d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: dw_hdmi: support ROCKCHIP_OUT_MODE_YUV420

VOP output mode and bus_format must be ROCKCHIP_OUT_MODE_YUV420
and MEDIA_BUS_FMT_YUV8_1X24 when display mode has a YCbCr420
flag.

Change-Id: Ib2d51c119f5a8f1b8a9285c47ab228b22a293d56
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

drm: bridge/dw_hdmi: support HDMI 2.0 YCbCr 4:2:0

Change-Id: I21fe667e8beeaf2f9b46fce043b6e14b366a3e05
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

ARM64: dts: rockchip: rk3368: add ramp-delay for syr82x dcdc

Change-Id: I61ef71b32aa708123909124b89f61e8a8f3a1bb7
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

mfd: rk818: use rk808-regulator

Change-Id: Ib7150f229a4682b6d0f4c5a6776a9ebc8565d221
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

drm: redefine YCbCr420 flag to bits 23:24

Since bits[19:22] have been used for picture aspect ratio
in upstream patch 876f43c073d79ad3f14a4cebd1aea1f39fc4daf5.
We define YCbCr420 flag to the subsequent bits.

Change-Id: I2eff8b51227fc7beb4f587e90bc070ae865ba9d4
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

UPSTREAM: drm: add picture aspect ratio flags

This patch adds drm flag bits for aspect ratio information

Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.

V2: Addressed review comments from Sean
- Changed PAR-> PIC_AR
V3: Rebase
V3: Added r-b by Jose

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1476705880-15600-2-git-send-email-shashank.sharma@intel.com
(cherry picked from commit 876f43c073d79ad3f14a4cebd1aea1f39fc4daf5)
Change-Id: I7dc4d82722d4824ba2b6c041080373175b8f6d18
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

drm/rockchip: gem: reorder pages if page chunk less than 8

Change-Id: I03a91d2f9c017086b3cb35edeaf6b7913b147b9b
Signed-off-by: Simon <xxm@rock-chips.com>

ARM64: dts: rk3399: Add pd/clk for iommu

Change-Id: I6da7372e82a031140fead601a0661260be75855b
Signed-off-by: Simon <xxm@rock-chips.com>

drm/rockchip: support YUV420 output mode

Change-Id: I7b991c544df6da81be93d84febe59fc5089895ca
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: vop: fixup color space table

Change-Id: Ia3c14602ffe837efd2fb4dcf8d3dd2c0960cfce6
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

video: rockchip: vcodec: add reg_rlc inside dec_pp

dec_pp also need to remap input fd.

Change-Id: Ic19a14a5ccc002b5be36d90ec3114244d5e494aa
Signed-off-by: Jung Zhao <jung.zhao@rock-chips.com>

ARM64: dts: rockchip: rk3399: invert the pwm polarity

invert the pwm polarity for new pwm interface

Change-Id: I8dfde14fbc4fd4aa907722f260ce72fdb4d7d3bb
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

video: backlight: pwm_bl: Fix the bug of Splashing screen when boot

The pwm_apply_args() should be removed when switching to the atomic
PWM API. Oherwise, the screen would splashing as the backlight is
disabled once when boot.

Change-Id: I0cadd471db54140192c39b9d7c6a673862e8f8d8
Signed-off-by: David Wu <david.wu@rock-chips.com>

pwm: rockchip: State of pwm clock should synchronize with pwm enabled state

If the pwm was not enabled at uboot loader, pwm could not work for clock
always disabled at pwm driver. The pwm clock is enabled at beginning of
pwm_apply(), but disabled at end of pwm_apply().

If the pwm was enabled at uboot loader, pwm clock is always enabled unless
closed by ATF. The pwm-backlight might turn off the power at early suspend,
should disable pwm clock for saving power consume.

It is important to provide opportunity to enable/disable clock at pwm driver,
the pwm consumer should ensure correct order to call pwm enable/disable, and
pwm driver ensure state of pwm clock synchronized with pwm enabled state.

Change-Id: I545db81eb638957567abacb93fd06fff9dd7181b
Fixes: 2bf1c98aa5a4 ("pwm: rockchip: Add support for atomic update")
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: cros-ec: Add __packed to prevent padding

While the particular usage in question is likely safe (struct
cros_ec_command is 32-bit aligned, followed by <= 32-bit fields), it's
been suggested this is not a great pattern to follow for the general
case -- for example, if we follow a 'struct cros_ec_command' (which is
32-bit- but not 64-bit-aligned) with a struct that starts with a 64-bit
type (e.g., u64), the compiler may add padding.

Let's add __packed, to inform the compiler of our true intention -- to
have no padding between these struct elements -- and to future proof for
any refactorings that might occur.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 065cfbbb638cce3d388020c4b97813b4a904a7c3)

Change-Id: Iddd499863dde168679a88c2f9ecc461316b417a0
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: Add ChromeOS EC PWM driver

Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control
one or more PWMs attached to the Embedded Controller. Because the EC
allows us to modify the duty cycle (as a percentage, where U16_MAX is
100%) but not the period, we assign the period a fixed value of
EC_PWM_MAX_DUTY and reject all attempts to change it.

This driver supports only device tree at the moment, because that
provides a very flexible way of describing the relationship between PWMs
and their consumer devices (e.g., backlight). On a non-DT system, we'll
probably want to use the non-GENERIC addressing (i.e., we'll need to
make special device instances that will use EC_PWM_TYPE_KB_LIGHT or
EC_PWM_TYPE_DISPLAY_LIGHT), as well as the relatively inflexible
pwm_lookup infrastructure for matching devices. Defer that work for now.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 1f0d3bb02785f698dc273b9006a473194c32f874)

Change-Id: I47dbb20b10ae1b941e50e9a783cb708dff8f7efd
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: dt-bindings: pwm: Add binding for ChromeOS EC PWM

The ChromeOS Embedded Controller can support controlling its attached
PWMs via its host-command interface. The number of supported PWMs varies
on a per-board basis, but we can autodetect this by checking the error
codes, so we don't need an extra property for this. And because the EC
only allows specifying the duty cycle and not the period, we don't
specify the period via pwm-cells, and instead have only support for one
cell -- to specify the index.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 9e60f50b4a79ae2df791d89d08cf2b78ad7629bd)

Change-Id: Ibb2ac5cff1e8cc2ab43c9f1f89e68e48da23d897
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range

Document the pwm-dutycycle-unit and pwm-dutycycle-range properties.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 58fd822b2e344edae6b4dbc09b19bd0c4a2f8f60)

Change-Id: I029307b54210f2203276a467e947d0fa2e51966d
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Support extra continuous mode cases

The continuous mode allows one to declare a PWM regulator without having
to declare the voltage <-> dutycycle association table. It works fine as
long as your voltage(dutycycle) function is linear, but also has the
following constraints:

- dutycycle for min_uV = 0%
- dutycycle for max_uV = 100%
- dutycycle for min_uV < dutycycle for max_uV

While the linearity constraint is acceptable for now, we sometimes need to
restrict of the PWM range (to limit the maximum/minimum voltage for
example) or have a min_uV_dutycycle > max_uV_dutycycle (this could be
tweaked with PWM polarity, but not all PWMs support inverted polarity).

Add the pwm-dutycycle-range and pwm-dutycycle-unit DT properties to define
such constraints. If those properties are not defined, the PWM regulator
use the default pwm-dutycycle-range = <0 100> and
pwm-dutycycle-unit = <100> values (existing behavior).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit ea398e28739e25651ede7ddf5aeb57cbcbc8ca7d)

Change-Id: I6e10c93a6620113e1463221d461fc23ccf3fe398
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: rockchip: Add support for atomic update

Implement the ->apply() function to add support for atomic update.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(commit 2bf1c98aa5a41651f5e6455117ff06f66ff3cc50)

Conflicts:
drivers/pwm/pwm-rockchip.c

Change-Id: I92745cf301c26d20da284da8234e244828598d52
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: rockchip: Avoid glitches on already running PWMs

The current logic will disable the PWM clk even if the PWM was left
enabled by the bootloader (because it's controlling a critical device
like a regulator for example).
Keep the PWM clk enabled if the PWM is enabled to avoid any glitches.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(commit 48cf973cae33488f84d7ab79a0f613383cff4de4)

Conflicts:
drivers/pwm/pwm-rockchip.c

Change-Id: I75ffccd19c5244568fc0034d1585dac490296111
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: rockchip: Add support for hardware readout

Implement the ->get_state() function to expose initial state.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 1ebb74cf3537135f157beddf1a4366070155edda)

Change-Id: Ia7454ce2f96ee814118724fa98bdd41d8b5ae922
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: rockchip: Fix period and duty cycle approximation

The current implementation always round down the duty and period values,
while it would be better to round them to the closest integer.

These changes are needed in preparation of atomic update support to
prevent a period/duty cycle drift when executing several times the
'pwm_get_state() / modify / pwm_apply_state()' sequence.

Say you have an expected period of 3.333 us and a clk rate of
112.666667 MHz -- the clock frequency doesn't divide evenly, so the
period (stashed in nanoseconds) shrinks when we convert to the register
value and back, as follows:

  pwm_apply_state(): register = period * 112666667 / 1000000000;
  pwm_get_state(): period = register * 1000000000 / 112666667;

or in other words:

  period = period * 112666667 / 1000000000 * 1000000000 / 112666667;

which yields a sequence like:

  3333 -> 3328
  3328 -> 3319
  3319 -> 3310
  3310 -> 3301
  3301 -> 3292
  3292 -> ... (etc) ...

With this patch, we'd see instead:

  period = div_round_closest(period * 112666667, 1000000000) *
                   1000000000 / 112666667;

which yields a stable sequence:

  3333 -> 3337
  3337 -> 3337
  3337 -> ... (etc) ...

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 12f9ce4a519845070d338253ab9528b5d7e2df34)

Change-Id: Ife75404e663d1380725d634ac621b2ca9f831791
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Retrieve correct voltage

The continuous PWM voltage regulator is caching the voltage value in
the ->volt_uV field. While most of the time this value should reflect the
real voltage, sometime it can be sightly different if the PWM device
rounded the set_duty_cycle request.
Moreover, this value is not valid until someone has modified the regulator
output.

Remove the ->volt_uV field and always rely on the PWM state to calculate
the regulator output.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit d9070fdbe40a04b61262bac0f7ff0c7c29a68015)

Change-Id: Iba7b143c1b08d547b5cd46ac42d9051fb34309df
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Properly initialize the ->state field

The ->state field is currently initialized to 0, thus referencing the
voltage selector at index 0, which might not reflect the current
voltage value.
If possible, retrieve the current voltage selector from the PWM state,
else return -EINVAL.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 87248991a1de28e73dc30057e82d831bc11cdd44)

Change-Id: I179395dc7bad7aa867e68c92be7ce92b03ae7112
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Switch to the atomic PWM API

Use the atomic API wherever appropriate and get rid of pwm_apply_args()
call (the reference period and polarity are now explicitly set when
calling pwm_apply_state()).

We also make use of the pwm_set_relative_duty_cycle() helper to ease
relative to absolute duty_cycle conversion.

Note that changes introduced by commit fd786fb0276a ("regulator: pwm:
Try to avoid voltage error in duty cycle calculation") are no longer
needed because pwm_set_relative_duty_cycle() takes care of all rounding
approximation for us.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 3f4eb39be9b1402ea01a5c67441d0b0bcb74b4b2)

Change-Id: Id12d4d625fb6e1e5ff3725737cc9232e4df40c36
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Adjust PWM config at probe time

The PWM attached to a PWM regulator device might have been previously
configured by the bootloader.
Make sure the bootloader and linux config are in sync, and adjust the PWM
config if that's not the case.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit fd4f99c4c3ce8ccd9b8ea751afc614a7624ecef2)

Change-Id: I06abddddc4666cd6510b6317795931f282e44eb0
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: Remove gratuitous blank line

Commit 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic
updates") introduced this double blank line by mistake.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 2b77487f2e8ff7e6496a7f5a08839de9bbb39ab3)

Change-Id: Ie84fc2496ae6ca111386fa42ab31b8ab0559bece
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: Add relative duty cycle manipulation helpers

The PWM framework expects PWM users to configure the duty cycle in nano-
seconds, but many users want to express the duty cycle relatively to the
period value (i.e. duty_cycle = 33% of the period).

Add the pwm_{get,set}_relative_duty_cycle() helpers to ease this kind of
conversion.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit f6f3bddf7b2b994a927808fcc5a3d07069c35956)

Change-Id: Ifffc72290225766a6006db6b18e6902ee51adb1c
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: Add a helper to prepare a new PWM state

The pwm_init_state() helper prepares a new state object containing the
current PWM state except for the polarity and period fields which are
set to the reference values (those in struct pwm_args).

This is particularly useful for PWM users who want to apply a new duty-
cycle expressed relatively to the reference period without changing the
enable state.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit a6a0dbbcfa469cf3e5c4d9522106c0b7b9e9e373)

Change-Id: Ib968e8fa6a49d5f853fc13cb4935e2af7494040f
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Fix regulator ramp delay for continuous mode

The original commit adding support for continuous voltage mode didn't
handle the regulator ramp delay properly.  It treated the delay as a
fixed delay in uS despite the property being defined as uV / uS.  Let's
adjust it.  Luckily there appear to be no users of this ramp delay for
PWM regulators (as per grepping through device trees in linuxnext).

Note also that the upper bound of usleep_range probably shouldn't be a
full 1 ms longer than the lower bound since I've seen plenty of hardware
with a ramp rate of ~5000 uS / uV and for small jumps the total delays
are in the tens of uS.  1000 is way too much.  We'll try to be dynamic
and use 10%.

NOTE: This commit doesn't add support for regulator-enable-ramp-delay.
That could be done in a future patch when someone has a user of that
featre.

Though this patch is shows as "fixing" a bug, there are no actual known
users of continuous mode PWM regulator w/ ramp delay in mainline and so
this likely won't have any effect on anyone unless they are working
out-of-tree with private patches.  For anyone in this state, it is
highly encouraged to also pick Boris Brezillon's WIP patches to get
yourself a reliable and glitch-free regulator.

Fixes: 4773be185a0f ("regulator: pwm-regulator: Add support for continuous-voltage")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit c2588393e6315ab68207323d37d2a73713d6bc81)

Change-Id: Ib0af8e04275813f333af12d48567b7e411b4d49f
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: Fix pwm_apply_args()

Commit 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic
updates"), implemented pwm_disable() as a wrapper around
pwm_apply_state(), and then, commit ef2bf4997f7d ("pwm: Improve args
checking in pwm_apply_state()") added missing checks on the ->period
value in pwm_apply_state() to ensure we were not passing inappropriate
values to the ->config() or ->apply() methods.

The conjunction of these 2 commits led to a case where pwm_disable()
was no longer succeeding, thus preventing the polarity setting done
in pwm_apply_args().

Set a valid period in pwm_apply_args() to ensure polarity setting
won't be rejected.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Suggested-by: Brian Norris <briannorris@chromium.org>
Fixes: 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic updates")
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 33cdcee04be3b4482be97393167e7561b2584e1e)

Change-Id: I9f28ae411953208b31c8d17214fce21e5177cee1
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Support for enable GPIO

Add an optional enable GPIO to the pwm-regulator driver.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 27bfa8893b15a3fa22a593c90a48c8bcb1f9c75b)

Change-Id: I6530165e6bccb4fc82d2916d169a02ecdcbfcd3e
Signed-off-by: David Wu <david.wu@rock-chips.com>