Change-Id: I3f3c3824df8887a32af75b0bbcd5d563de547638

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Icd1ce71443e4d4968e28826d86b7c5b39d0f9b13

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Ia8d4869ff336ad6a2deed92bff2190509507b948
Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: If5ad26b1f2619b478f4a025db223267e2e3e69fc
Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I1a7a986103093d7cd85d8824344e8b3516fb9da4

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Id7dd38ad04acc60475959a40914ada55795ee5ec

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I6807fbd278772a8913f767b1de389f3d4258390d

Signed-off-by: Dongjin Kim <[email protected]>

Below hardware/components are deprecated
        PMU (AML1618)
        NAND
        Audio Codec

Change-Id: Ica61b729b1fc8abc8df9bb60d84279c3f0269d85
Signed-off-by: Dongjin Kim <[email protected]>

…'s that we don't use.

Change-Id: I67faa37a58bc77c77ec560027ba50ec24c3cc417

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Iedf453c1bdd01bd1682ec2bce4d2e0148153ece2
(cherry picked from commit f6d103a55073201fad32407a1ff125f4b822d2c8)

Change-Id: I2cb76fb311398e36bb6f4a5aff14e9c0975d12cd
Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Id5656c4f5404864d4536972beed7fa352ba77eb5
Signed-off-by: ckkim <[email protected]>
Signed-off-by: Dongjin Kim <[email protected]>

drivers/mtd/nand/nand_base.c:2863:12:
error: ‘nand_flash_detect_onfi’ defined but not used [-Werror=unused-function]
cc1: all warnings being treated as errors

Change-Id: I66511666e9dc561ae8adc06d73aa21b3856d3a37
Signed-off-by: Dongjin Kim <[email protected]>
(cherry picked from commit 00abfbee13b5210ea67b6abf4fe5f7dc12a57ee3)

Change-Id: I5dabc4071c2f1d2d4f4ea550097b990757c74e99
Signed-off-by: Kevin Kim <[email protected]>
(cherry picked from commit 18dc68ff78151320c4a6133f5731448d2ac4f500)
Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I13f9faff4b386773f305f447a882457fa22888a7

Change-Id: Ied4e43e5cb17d24a5abd7d0736c45df74d507bea

Change-Id: Ia8d4869ff336ad6a2deed92bff2190509507b948
Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Ic81139b6a58f04f9e4d8126f0d1b1bf8287a3d45
Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Id35540e7809515d9bf7b1a30fbfbc76775e0b4d9
Signed-off-by: Kevin Kim <[email protected]>

Since ODROIDC does not have PMU for voltage scaling, only required to
scale the CPU frequencies.

Change-Id: I6e49d7b00fb057776e97fafc3a1dc6daa8494e1e

Change-Id: Ideaf2d3b9d887e7442a589c988bd1d2a12a951bb
Signed-off-by: Kevin Kim <[email protected]>

Change-Id: I80d7bb91cc49f2cd4cdb8d961bcdea35f98ef7a1
(cherry picked from commit 5162ac8869a36453a8918e6d16d657f3d864dd3f)

In order to assign a boot media to SDHC block between SDCARD or eMMC,
different two device tree have to be maintained. But this is risky to
maintain. Hence add both properties of SDCARD and eMMC to each contoller, SDHC
and SDIO, remove one of them in U-boot. Finally Linux kernel will have proper
device tree with corresponding to boot deivce.

Change-Id: I607575123f81e85d93c0c2613738e11f53892731
Signed-off-by: Dongjin Kim <[email protected]>

Conflicts:
	arch/arm/boot/dts/amlogic/meson8b_odroidc.dtd

Since MESON8B has single SDHC and SDIO block, 'meson8b_odroidc.dtd' is to boot by sdcard
and 'meson8b_odroidc_emmc.dtd' by eMMC.

Change-Id: I5550197122c023d50665a3bcfc740567b99420f4

Conflicts:
	arch/arm/boot/dts/amlogic/meson8b_odroidc.dtd

Change-Id: If1ecefd4140bd688c9124d0bd7e6e1929b747a7a

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Ib6ca8501ac7527c15d11721dab42e2e5b341169a

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Id465074a80b67925896295b7818e68830dbeaccb

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I62850b6e4477bf6e22709f616b9db23e908d89f4

Signed-off-by: Dongjin Kim <[email protected]>

…nge on monitor. This makes the 480p@60hz work.

Change-Id: Ia793bdf1cf1e3cf4bd24d5b8086c0fb9ae97a09e

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I4bcf208fceb8bf66723955658b21bd35cc2df8ef
Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I48c9c2851accfaff733cb33933388a6e51be47bd
Signed-off-by: Dongjin Kim <[email protected]>

This reverts commit 34e3ccb261b48dc64a4b79770980807baae125d3.

Change-Id: I6dd61f28ff003ae4c35c4b79bec29a75c6562bca

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I0789ff649a462e00f62705d8b3b08ef5c27a8b82
(cherry picked from commit 577b9c2c49122ea751175530ffca3ffa5d7ec494)

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I19c109832211318a261cf40685218bffd165633d

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I1e01159f21b213083be374f22c0342343e935525
Signed-off-by: Dongjin Kim <[email protected]>
(cherry picked from commit 74295dc1264095a78083bbb84c196306d2938318)

Change-Id: I22cd831d5586bd91d93cb32722e596eab21e60af
Signed-off-by: Dongjin Kim <[email protected]>
(cherry picked from commit b9713f6c1c9dd8b3f5ed2c5976d5f59927c95abf)

…x it

Change-Id: I9b8f22a9c4c02c377e8035068aec4727fa6b9fc4

Signed-off-by: Dongjin Kim <[email protected]>

…properly

Change-Id: I621882c117c8c29e76c7ca1f666f1557a145e3be

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I80b22cccf872ab3b27be5c4c5e2f033f74a54eed

Signed-off-by: Dongjin Kim <[email protected]>

…x86 binary

Change-Id: Ic5faf36677a01e564593f5850c1c83f40a75685c

Signed-off-by: Dongjin Kim <[email protected]>

Since ODROID-C does not PMU, it won't stop or off completely. Hence this
reboot condition will reach to bootloader and halt the system.

Change-Id: I6bb8c5628bfbf0f9c120062fe7cb207aeb2aac2c
Signed-off-by: Dongjin Kim <[email protected]>
(cherry picked from commit 2bbc6b65c4586cf0e78cffadd490d8156d3f5133)

Since AMLogic's GPIOLIB does not support standard framework yet,
of_get_named_gpio_flags is replaced to use AMLogic's own framework such that
GPIO will be obtained from wrapper function.

Change-Id: I29b5a3bc99bbfa7b299c575b08e10fea81935cef

Signed-off-by: Dongjin Kim <[email protected]>

AMLogic drivers doesn't like resetting the same mode.
So this is only for sanity reasons and prevent a blanking screen with certain variations of logo= and hdmimode=

Change-Id: Id4e403eadcc892fc2a2979f3776f8e2c45469d5b

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Ibc31893ee1c02614ebd81449b4af642919e8f5ba

Change-Id: I0c0476ac4f20f0059ba6dd8125d3ced20bfec7fc

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I49db713431d4ce147a8894847790242900efb3e9

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I0d0c16d6186ad4a06a7a57c31c81c9104561bca0

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I1fb6f592aa87fd1466b3b0642d89f090537c4a72

Change-Id: I9997f2e900260c1164afc4c8cd7346a21ab52846

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I8428c5a6890299f09b182760e7320112c2ed7353
Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I14851a8b7fba873b4ea7646d43a363a0e581f0af

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I5312ef87b3c48b0ca8e40c95f46bc79e38c24c17

Conflicts:
        arch/arm/boot/dts/amlogic/meson8b_odroidc.dtd

Change-Id: Ieb5d77974bcf54feb79505aece1375efb867accd

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: I9ef503fe3f581b4f84de57c7119d3ec6333d3d21
Signed-off-by: Dongjin Kim <[email protected]>

This patch is to deprecate AMLogic's DVFS driver since ODROID-C does not
PMU. This driver prevent to reach maximum cpufreq while changing the
voltage according to the requested frequency in the function aml_dvfs_do_voltage_change.

Change-Id: Iec5352c676f8bae36ebec1bdf2d849f0aa290ceb
Signed-off-by: Dongjin Kim <[email protected]>

Using the configuration like this will keep mali at 425Mhz
And uppon any even to the GPU boost it to the max frequency and keep it there.

Change-Id: I434bbc9ebc7a6aeb619e632436eceaa8c7683ced

Signed-off-by: Dongjin Kim <[email protected]>

Change-Id: Ib64ac1ff81963f38dc2cbe0988a518cc92c789a5

Signed-off-by: Dongjin Kim <[email protected]>

This reverts commit eccdca38c95e50dc61f4669e94e94b8ba44e78a5.

Conflicts:
	arch/arm/boot/dts/amlogic/meson8b_odroidc.dtd

Change-Id: I5d4a4e753e5b602742ec28ccc2b2d8aea8ce9b46

Change-Id: I900dd5a6c1e66827b6d39e4c4c02c7bacaa8daf0

Change-Id: I64ab193bbec63f2baafc4213d546dcc720be610a

This patch is to disable CLK_OUT unused and enable Spread Spectrum Clock on RXC
SSC and System Clock.

Change-Id: I1e9a689de9f77348fbb705071eb8047d5c5aca73
Signed-off-by: Dongjin Kim <[email protected]>

…spidev)

Change-Id: Ie54b76badea67651101fe5ee12adc494941e7d56

commit fb993fa upstream.

If a frontswap dup-store failed, it should invalidate the expired page
in the backend, or it could trigger some data corruption issue.
Such as:
 1. use zswap as the frontswap backend with writeback feature
 2. store a swap page(version_1) to entry A, success
 3. dup-store a newer page(version_2) to the same entry A, fail
 4. use __swap_writepage() write version_2 page to swapfile, success
 5. zswap do shrink, writeback version_1 page to swapfile
 6. version_2 page is overwrited by version_1, data corrupt.

This patch fixes this issue by invalidating expired data immediately
when meet a dup-store failure.

Signed-off-by: Weijie Yang <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: Seth Jennings <[email protected]>
Cc: Dan Streetman <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Bob Liu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2022b4d upstream.

I've been seeing swapoff hangs in recent testing: it's cycling around
trying unsuccessfully to find an mm for some remaining pages of swap.

I have been exercising swap and page migration more heavily recently,
and now notice a long-standing error in copy_one_pte(): it's trying to
add dst_mm to swapoff's mmlist when it finds a swap entry, but is doing
so even when it's a migration entry or an hwpoison entry.

Which wouldn't matter much, except it adds dst_mm next to src_mm,
assuming src_mm is already on the mmlist: which may not be so.  Then if
pages are later swapped out from dst_mm, swapoff won't be able to find
where to replace them.

There's already a !non_swap_entry() test for stats: move that up before
the swap_duplicate() and the addition to mmlist.

Signed-off-by: Hugh Dickins <[email protected]>
Cc: Kelley Nielsen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

…dary

commit 8d60972 upstream.

These BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.

Fixes: f36c374 ("xen/netfront: handle compound page fragments on transmit")
Signed-off-by: Seth Forshee <[email protected]>
Reviewed-by: David Vrabel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 27caca9 upstream.

commit 1d7afc9 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
fired again. As a result, ISR keep processing transfer after it was already
complete (from the driver code point of view).

A didn't see real impacts of the 1d7afc9, but it is really bad idea to
have ISR running on user data after transfer was complete.

It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).

According to specs (if I understood correctly), in case of NACK and AL driver
must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
NACK, AL, ARDY, and XDR (Master Transmitter Mode).

All that is done down the code under the if condition:
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...

The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
no interrupts is fired after ISR informs the rest of driver what transfer
complete.

Note: instead of removing break under NACK case, we could just replace 'break'
with 'continue' and allow NACK transfer to finish using ARDY event. I found
that NACK and ARDY bits usually set together. That case confirm TI wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK

In order if someone interested in the event traces for NACK and AL cases,
I sent them to mailing list.

Tested on Beagleboard XM C.

Signed-off-by: Alexander Kochetkov <[email protected]>
Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
Acked-by: Felipe Balbi <[email protected]>
Tested-by: Aaro Koskinen <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ccfc866 upstream.

commit 6d9939f (i2c: omap: split out [XR]DR
and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
Set) get handled. 6d9939f code doesn't correspond to workaround provided by
errata.

According to errata ISR must filter out spurious RDR before data read not after.
ISR must read RXSTAT to get number of bytes available to read. Because RDR
could be set while there could no data in the receive FIFO.

Restored pre 6d9939f way of handling errata.

Found by code review. Real impact haven't seen.
Tested on Beagleboard XM C.

Signed-off-by: Alexander Kochetkov <[email protected]>
Fixes: 6d9939f i2c: omap: split out [XR]DR and [XR]RDY
Tested-by: Felipe Balbi <[email protected]>
Reviewed-by: Felipe Balbi <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9ea359f upstream.

According to I2C specification the NACK should be handled as follows:
"When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then generate either a STOP condition to
abort the transfer, or a repeated START condition to start a new transfer."
[I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]

Currently the Davinci i2c driver interrupts the transfer on receipt of a
NACK but fails to send a STOP in some situations and so makes the bus
stuck until next I2C IP reset (idle/enable).

For example, the issue will happen during SMBus read transfer which
consists from two i2c messages write command/address and read data:

S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P
<--- write -----------------------> <--- read --------------------->

The I2C client device will send NACK if it can't recognize "Command Code"
and it's expected from I2C master to generate STP in this case.
But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will
not be generated.

Hence, fix it by generating Stop condition (STP) always when NACK is received.

This patch fixes Davinci I2C in the same way it was done for OMAP I2C
commit cda2109 ("i2c: omap: query STP always when NACK is received").

Reviewed-by: Uwe Kleine-König <[email protected]>
Reported-by: Hein Tibosch <[email protected]>
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

…h 3.18.0-rc6

commit f5475cc upstream.

I was unable too boot 3.18.0-rc6 because of the following kernel
panic in drm_calc_vbltimestamp_from_scanoutpos():

    [drm] Initialized drm 1.1.0 20060810
    [drm] radeon kernel modesetting enabled.
    [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
    [drm] register mmio base: 0xC8400000
    [drm] register mmio size: 65536
    radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
    radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
    [drm] Detected VRAM RAM=128M, BAR=128M
    [drm] RAM width 16bits DDR
    [TTM] Zone  kernel: Available graphics memory: 3829346 kiB
    [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
    [TTM] Initializing pool allocator
    [TTM] Initializing DMA pool allocator
    [drm] radeon: 16M of VRAM memory ready
    [drm] radeon: 512M of GTT memory ready.
    [drm] GART: num cpu pages 131072, num gpu pages 131072
    [drm] PCI GART of 512M enabled (table at 0x0000000037880000).
    radeon 0000:0b:01.0: WB disabled
    radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
    [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
    [drm] Driver supports precise vblank timestamp query.
    [drm] radeon: irq initialized.
    [drm] Loading R100 Microcode
    radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
    radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
    [drm:r100_cp_init] *ERROR* Failed to load firmware!
    radeon 0000:0b:01.0: failed initializing CP (-2).
    radeon 0000:0b:01.0: Disabling GPU acceleration
    [drm] radeon: cp finalized
    BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
    IP: [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
    PGD 0
    Oops: 0000 [hardkernel#1] SMP
    Modules linked in:
    CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
    Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
    task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
    RIP: 0010:[<ffffffff8150423b>]  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
    RSP: 0000:ffff880234da7918  EFLAGS: 00010086
    RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
    RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
    RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
    R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
    R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
    FS:  0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
    Stack:
     ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
     ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
     ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
    Call Trace:
     [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110
     [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60
     [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180
     [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70
     [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0
     [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70
     [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0
     [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70
     [<ffffffff8156c07e>] r100_init+0x26e/0x410
     [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50
     [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210
     [<ffffffff81506965>] drm_dev_register+0xb5/0x110
     [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200
     [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0
     [<ffffffff8141a365>] local_pci_probe+0x45/0xa0
     [<ffffffff8141b741>] pci_device_probe+0xd1/0x130
     [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0
     [<ffffffff8163413b>] __driver_attach+0x9b/0xa0
     [<ffffffff816340a0>] ? __device_attach+0x40/0x40
     [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0
     [<ffffffff8163378e>] driver_attach+0x1e/0x20
     [<ffffffff81633390>] bus_add_driver+0x180/0x240
     [<ffffffff81634914>] driver_register+0x64/0xf0
     [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50
     [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120
     [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a
     [<ffffffff821dc908>] radeon_init+0x97/0xb5
     [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0
     [<ffffffff810e3278>] ? __wake_up+0x48/0x60
     [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215
     [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0
     [<ffffffff818a78f0>] ? rest_init+0x80/0x80
     [<ffffffff818a78fe>] kernel_init+0xe/0xf0
     [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0
     [<ffffffff818a78f0>] ? rest_init+0x80/0x80
    Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
    RIP  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
     RSP <ffff880234da7918>
    CR2: 000000000000025c
    ---[ end trace ad2c0aadf48e2032 ]---
    Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

It has helped me to add a NULL pointer check that was suggested at
http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html

I am not familiar with the code. But the change looks sane
and we need something fast at this stage of 3.18 development.

Suggested-by: Helge Deller <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Tested-by: Petr Mladek <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b0616c5 upstream.

Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced in

commit c31407a
Author: Chris Wilson <[email protected]>
Date:   Thu Oct 18 21:07:01 2012 +0100

    drm/i915: Add no-lvds quirk for Supermicro X7SPA-H

Reported-by: Alexey Orishko <[email protected]>
Cc: Alexey Orishko <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Francois Tigeot <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Tested-by: Alexey Orishko <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b31eb90 upstream.

Setting a non-settable selection target caused BUG() to be called. The check
for valid selections only takes the selection target into account, but does
not tell whether it may be set, or only get. Fix the issue by simply
returning an error to the user.

Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 249cd0a upstream.

This patch adds DeviceIDs for Sunrise Point-LP.

Signed-off-by: Devin Ryles <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2b21ef0 upstream.

Just like 0x1600 which got blacklisted by 66a7cbc ("ahci: disable
MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes
on NCQ commands if MSI is enabled.  Disable MSI.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Dominik Mierzejewski <[email protected]>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit aad0b62 upstream.

irq_of_parse_and_map() returns 0 on error (the result is unsigned int),
so testing for negative result never works.

Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit be6572f ]

When using GRE redirection in WCCP, it sets the wrong skb->protocol,
that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic.

Fixes: c12b395 ("gre: Support GRE over IPv6")
Cc: Dmitry Kozlov <[email protected]>
Signed-off-by: Yuri Chislov <[email protected]>
Tested-by: Yuri Chislov <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit a620a6b ]

If TX channels are set to 4 and RX channels are set to less than 4,
using ethtool -L, the driver will try to initialize more RX channels
than it has allocated, causing an oops.

This fix only initializes the RX ring if it has been allocated.

Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 2d5c57d ]

Some VF drivers use the upper byte of "param1" (the qp count field)
in mlx4_qp_reserve_range() to pass flags which are used to optimize
the range allocation.

Under the current code, if any of these flags are set, the 32-bit
count field yields a count greater than 2^24, which is out of range,
and this VF fails.

As these flags represent a "best-effort" allocation hint anyway, they may
safely be ignored. Therefore, the PF driver may simply mask out the bits.

Fixes: c82e9aa "mlx4_core: resource tracking for HCA resources used by guests"
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit e0ebde0 ]

rtnl_link_get_net() holds a reference on the 'struct net', we need to release
it in case of error.

CC: Eric W. Biederman <[email protected]>
Fixes: b51642f ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
Signed-off-by: Nicolas Dichtel <[email protected]>
Reviewed-by: "Eric W. Biederman" <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit aebea2b ]

The mvneta driver sets the amount of Tx coalesce packets to 16 by
default. Normally that does not cause any trouble since the driver
uses a much larger Tx ring size (532 packets). But some sockets
might run with very small buffers, much smaller than the equivalent
of 16 packets. This is what ping is doing for example, by setting
SNDBUF to 324 bytes rounded up to 2kB by the kernel.

The problem is that there is no documented method to force a specific
packet to emit an interrupt (eg: the last of the ring) nor is it
possible to make the NIC emit an interrupt after a given delay.

In this case, it causes trouble, because when ping sends packets over
its raw socket, the few first packets leave the system, and the first
15 packets will be emitted without an IRQ being generated, so without
the skbs being freed. And since the socket's buffer is small, there's
no way to reach that amount of packets, and the ping ends up with
"send: no buffer available" after sending 6 packets. Running with 3
instances of ping in parallel is enough to hide the problem, because
with 6 packets per instance, that's 18 packets total, which is enough
to grant a Tx interrupt before all are sent.

The original driver in the LSP kernel worked around this design flaw
by using a software timer to clean up the Tx descriptors. This timer
was slow and caused terrible network performance on some Tx-bound
workloads (such as routing) but was enough to make tools like ping
work correctly.

Instead here, we simply set the packet counts before interrupt to 1.
This ensures that each packet sent will produce an interrupt. NAPI
takes care of coalescing interrupts since the interrupt is disabled
once generated.

No measurable performance impact nor CPU usage were observed on small
nor large packets, including when saturating the link on Tx, and this
fixes tools like ping which rely on too small a send buffer. If one
wants to increase this value for certain workloads where it is safe
to do so, "ethtool -C $dev tx-frames" will override this default
setting.

This fix needs to be applied to stable kernels starting with 3.10.

Tested-By: Maggie Mae Roxas <[email protected]>
Signed-off-by: Willy Tarreau <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 9772b54 ]

To accomodate for enough headroom for tunnels, use MAX_HEADER instead
of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs
of trinity an skb_under_panic() via SCTP output path (see reference).
I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere
in other protocols might be one possible cause for this.

In any case, it looks like accounting on chunks themself seems to look
good as the skb already passed the SCTP output path and did not hit
any skb_over_panic(). Given tunneling was enabled in his .config, the
headroom would have been expanded by MAX_HEADER in this case.

Reported-by: Robert Święcki <[email protected]>
Reference: https://lkml.org/lkml/2014/12/1/507
Fixes: 594ccc1 ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().")
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Vlad Yasevich <[email protected]>
Acked-by: Neil Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bfd0a56 upstream.

If we let L1 use EPT, we should probably also support the INVEPT instruction.

In our current nested EPT implementation, when L1 changes its EPT table
for L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in
the course of this modification already calls INVEPT. But if last level
of shadow page is unsync not all L1's changes to EPT12 are intercepted,
which means roots need to be synced when L1 calls INVEPT. Global INVEPT
should not be different since roots are synced by kvm_mmu_load() each
time EPTP02 changes.

Reviewed-by: Xiao Guangrong <[email protected]>
Signed-off-by: Nadav Har'El <[email protected]>
Signed-off-by: Jun Nakajima <[email protected]>
Signed-off-by: Xinhao Xu <[email protected]>
Signed-off-by: Yang Zhang <[email protected]>
Signed-off-by: Gleb Natapov <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
[bwh: Backported to 3.2:
 - Adjust context, filename
 - Simplify handle_invept() as recommended by Paolo - nEPT is not
   supported so we always raise #UD]
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Vinson Lee <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit df4e7ac upstream.

ext2_quota_write() doesn't properly setup bh it passes to
ext2_get_block() and thus we hit assertion BUG_ON(maxblocks == 0) in
ext2_get_blocks() (or we could actually ask for mapping arbitrary number
of blocks depending on whatever value was on stack).

Fix ext2_quota_write() to properly fill in number of blocks to map.

Reviewed-by: "Theodore Ts'o" <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reported-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit aec653c upstream.

Call igb_setup_link() when the PHY is powered up.

Signed-off-by: Todd Fujinaka <[email protected]>
Reported-by: Jeff Westfahl <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Cc: Vincent Donnefort <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 336ae11 upstream.

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:

 CPU0                           CPU1
 ----                           ----
 cyc = read_sched_clock()
 cyc_to_sched_clock()
                                 update_sched_clock()
                                  ...
                                  cd.epoch_cyc = cyc;
  epoch_cyc = cd.epoch_cyc;
  ...
  epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has
stabilized.

Cc: Russell King <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 152d44a upstream.

I used some 64 bit instructions when adding the 32 bit getcpu VDSO
function. Fix it.

Fixes: 18ad51d ("powerpc: Add VDSO version of getcpu")
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 66139a4 upstream.

In snd_usbmidi_error_timer(), the driver tries to resubmit MIDI input
URBs to reactivate the MIDI stream, but this causes the error when
some of URBs are still pending like:

 WARNING: CPU: 0 PID: 0 at ../drivers/usb/core/urb.c:339 usb_submit_urb+0x5f/0x70()
 URB ef705c40 submitted while active
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.6-2-desktop hardkernel#1
 Hardware name: FOXCONN TPS01/TPS01, BIOS 080015  03/23/2010
  c0984bfa f4009ed4 c078deaf f4009ee4 c024c884 c09a135c f4009f00 00000000
  c0984bfa 00000153 c061ac4f c061ac4f 00000009 00000001 ef705c40 e854d1c0
  f4009eec c024c8d3 00000009 f4009ee4 c09a135c f4009f00 f4009f04 c061ac4f
 Call Trace:
  [<c0205df6>] try_stack_unwind+0x156/0x170
  [<c020482a>] dump_trace+0x5a/0x1b0
  [<c0205e56>] show_trace_log_lvl+0x46/0x50
  [<c02049d1>] show_stack_log_lvl+0x51/0xe0
  [<c0205eb7>] show_stack+0x27/0x50
  [<c078deaf>] dump_stack+0x45/0x65
  [<c024c884>] warn_slowpath_common+0x84/0xa0
  [<c024c8d3>] warn_slowpath_fmt+0x33/0x40
  [<c061ac4f>] usb_submit_urb+0x5f/0x70
  [<f7974104>] snd_usbmidi_submit_urb+0x14/0x60 [snd_usbmidi_lib]
  [<f797483a>] snd_usbmidi_error_timer+0x6a/0xa0 [snd_usbmidi_lib]
  [<c02570c0>] call_timer_fn+0x30/0x130
  [<c0257442>] run_timer_softirq+0x1c2/0x260
  [<c0251493>] __do_softirq+0xc3/0x270
  [<c0204732>] do_softirq_own_stack+0x22/0x30
  [<c025186d>] irq_exit+0x8d/0xa0
  [<c0795228>] smp_apic_timer_interrupt+0x38/0x50
  [<c0794a3c>] apic_timer_interrupt+0x34/0x3c
  [<c0673d9e>] cpuidle_enter_state+0x3e/0xd0
  [<c028bb8d>] cpu_idle_loop+0x29d/0x3e0
  [<c028bd23>] cpu_startup_entry+0x53/0x60
  [<c0bfac1e>] start_kernel+0x415/0x41a

For avoiding these errors, check the pending URBs and skip
resubmitting such ones.

Reported-and-tested-by: Stefan Seyfried <[email protected]>
Acked-by: Clemens Ladisch <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

…rent way that the kernel works

Change-Id: I900adb1ab3bb7e98ab0f9adcfb189ad46ad9447e

Change-Id: I47bfc201890eb4968f0964bce2a711ff90d67795

Change-Id: Ia4151e0c71aa8987d91bb53a72cd223c66e5d7dd

Change-Id: I50b5854a037e8fdb46a30883c613f5758cf425fc

Change-Id: I5e2c6c2ff1108a7024a5258d3d14d4d944b9cbd3

Change-Id: I6ccba12b32e4601a9b70bcf7610b89860e0dcf56

Change-Id: I4fdb1ddded9d1a4bdf641b59b9082b8a03c1ffb4

Change-Id: I2b7833c0f7ee243c886eef0309a6f89b53a32e77

…/stable/linux-stable into odroidc-3.10.y

This is the 3.10.34 stable release

Change-Id: I19a57b26d026adf616add626071228281e2b758b