{"push_id":1190944109,"size":107,"distinct_size":0,"ref":"refs/heads/caf/linux-next/stable","head":"a99cde438de0c4c0cecc1d1af1a55a75b10bfdef","before":"1a0a02d1efa066001fd315c1b4df583d939fa2c4","commits":[{"sha":"bea8205feeb1d28841541814ae375defb5b1986b","author":{"name":"Mark Brown","email":"bf2c7ef56f4d087c7cc4d81e9839c8674e3b6b2e@kernel.org"},"message":"Merge branch 'asoc-fix-ep93xx' into spi-fix-ep93xx","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/bea8205feeb1d28841541814ae375defb5b1986b"},{"sha":"595144c1141c951a3c6bb9004ae6a2bc29aad66f","author":{"name":"Heiko Stuebner","email":"f67af7135bf5422071c7efd95ce8a74473489823@sntech.de"},"message":"clk: rockchip: initialize flags of clk_init_data in mmc-phase clock\n\nThe flags element of clk_init_data was never initialized for mmc-\nphase-clocks resulting in the element containing a random value\nand thus possibly enabling unwanted clock flags.\n\nFixes: 89bf26cbc1a0 (\"clk: rockchip: Add support for the mmc clock phases using the framework\")\nCc: stable@vger.kernel.org\nSigned-off-by: Heiko Stuebner <heiko@sntech.de>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/595144c1141c951a3c6bb9004ae6a2bc29aad66f"},{"sha":"176df69cb080c8cd813e51f800069e13ee607641","author":{"name":"Brian Norris","email":"6171de59f5d877bdf30f45ca152231ebf21255a1@chromium.org"},"message":"clk: rockchip: mark rk3399 GIC clocks as critical\n\nWe never want to kill the GIC.\n\nNoticed when making other clock fixups, and seeing the newly-constructed\nclock tree try to disable cpll, where we had this parent structure:\n\n  aclk_gic <------\\\n                  |--- aclk_gic_pre <-- cpll <-- pll_cpll\n  aclk_gic_noc <--/\n\nSigned-off-by: Brian Norris <briannorris@chromium.org>\nReviewed-by: Douglas Anderson <dianders@chromium.org>\nSigned-off-by: Heiko Stuebner <heiko@sntech.de>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/176df69cb080c8cd813e51f800069e13ee607641"},{"sha":"3bd14ae9da9194d369334556a70a7ff73ef94491","author":{"name":"Xing Zheng","email":"2bdfef9cb1295ebcc2755d42cb44bb943abaa9f5@rock-chips.com"},"message":"clk: rockchip: fix incorrect parent for rk3399's {c,g}pll_aclk_perihp_src\n\nThere was a typo, swapping 'c' <--> 'g'.\n\nSigned-off-by: Xing Zheng <zhengxing@rock-chips.com>\nSigned-off-by: Brian Norris <briannorris@chromium.org>\nReviewed-by: Douglas Anderson <dianders@chromium.org>\nSigned-off-by: Heiko Stuebner <heiko@sntech.de>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/3bd14ae9da9194d369334556a70a7ff73ef94491"},{"sha":"4715f81afc342996f680b08c944a712d9cbef11b","author":{"name":"Douglas Anderson","email":"654d5d600e907ff4a0e75ec2e21c072be3e1556d@chromium.org"},"message":"clk: rockchip: Revert \"clk: rockchip: reset init state before mmc card initialization\"\n\nThis reverts commit 7a03fe6f48f3 (\"clk: rockchip: reset init state\nbefore mmc card initialization\").\n\nThough not totally obvious from the commit message nor from the source\ncode, that commit appears to be trying to reset the \"_drv\" MMC clocks to\n90 degrees (note that the \"_sample\" MMC clocks have a shift of 0 so are\nnot touched).\n\nThe major problem here is that it doesn't properly reset things.  The\nphase is a two bit field and the commit only touches one of the two\nbits.  Thus the commit had the following affect:\n- phase   0  => phase  90\n- phase  90  => phase  90\n- phase 180  => phase 270\n- phase 270  => phase 270\n\nThings get even weirder if you happen to have a bootloader that was\nactually using delay elements (should be no reason to, but you never\nknow), since those are additional bits that weren't touched by the\noriginal patch.\n\nThis is unlikely to be what we actually want.  Checking on rk3288-veyron\ndevices, I can see that the bootloader leaves these clocks as:\n- emmc:  phase 180\n- sdmmc: phase 90\n- sdio0: phase 90\n\nThus on rk3288-veyron devices the commit we're reverting had the effect\nof changing the eMMC clock to phase 270.  This probably explains the\nscattered reports I've heard of eMMC devices not working on some veyron\ndevices when using the upstream kernel.\n\nThe original commit was presumably made because previously the kernel\ndidn't touch the \"_drv\" phase at all and relied on whatever value was\nthere when the kernel started.  If someone was using a bootloader that\ntouched the \"_drv\" phase then, indeed, we should have code in the kernel\nto fix that.  ...and also, to get ideal timings, we should also have the\nkernel change the phase depending on the speed mode.  In fact, that's\nthe subject of a recent patch I posted at\n<https://patchwork.kernel.org/patch/9075141/>.\n\nIdeally, we should take both the patch posted to dw_mmc and this\nrevert.  Since those will likely go through different trees, here I\ndescribe behavior with the combos:\n\n1. Just this revert: likely will fix rk3288-veyron eMMC on some devices\n   + other cases; might break someone with a strange bootloader that\n   sets the phase to 0 or one that uses delay elements (pretty\n   unpredicable what would happen in that case).\n2. Just dw_mmc patch: fixes everyone.  Effectly the dw_mmc patch will\n   totally override the broken patch and fix everything.\n3. Both patches: fixes everyone.  Once dw_mmc is initting properly then\n   any defaults from the clock code doesn't mattery.\n\nFixes: 7a03fe6f48f3 (\"clk: rockchip: reset init state before mmc card initialization\")\nSigned-off-by: Douglas Anderson <dianders@chromium.org>\nReviewed-by: Shawn Lin <shawn.lin@rock-chips.com>\n\n[emmc and sdmmc still work on all current boards in mainline after this\nrevert, so they should take precedence over any out-of-tree board that\nwill hopefully again get fixed with the better upcoming dw_mmc change.]\nSigned-off-by: Heiko Stuebner <heiko@sntech.de>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/4715f81afc342996f680b08c944a712d9cbef11b"},{"sha":"3183c0d519ff83af2926382c11716496f01d34bf","author":{"name":"Xing Zheng","email":"2bdfef9cb1295ebcc2755d42cb44bb943abaa9f5@rock-chips.com"},"message":"clk: rockchip: fix cpuclk registration error handling\n\nIt maybe due to a copy-paste error the error handing should be\ncclk not clk when checking if the cpuclk registration succeeded.\n\nReported-by: Lin Huang <lin.huang@rock-chips.com>\nSigned-off-by: Xing Zheng <zhengxing@rock-chips.com>\nSigned-off-by: Heiko Stuebner <heiko@sntech.de>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/3183c0d519ff83af2926382c11716496f01d34bf"},{"sha":"3ac066e2227cb272c097f34475247fa0a6cdd2ff","author":{"name":"Jean-Jacques Hiblot","email":"57230d54682887a5030660f0d67327b9a3dfa1d8@ti.com"},"message":"spi: spi-ti-qspi: Suspend the queue before removing the device\n\nBefore disabling the pm_runtime, we must ensure that there is no transfer\nin progress nor will a new one be started. Otherwise the message pump will\nfail and in the end, the process requesting the transfer will be stuck.\nThis behavior has been observed when transferring data from a SPI flash\nwith dd while removing the module on a DRA7x-evm.\n\nSigned-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/3ac066e2227cb272c097f34475247fa0a6cdd2ff"},{"sha":"62d0e71df063101e4551327bd9fa9aaa3535c86b","author":{"name":"Shawn Lin","email":"d05afb63fc7c176eb2c681ec3e64badcfb02edcb@rock-chips.com"},"message":"clk: rockchip: release io resource when failing to init clk on rk3399\n\nWe should call iounmap to relase reg_base since it's not going\nto be used any more if failing to init clk.\n\nThis was missing on the newly added rk3399 clock tree.\n\nSigned-off-by: Shawn Lin <shawn.lin@rock-chips.com>\nSigned-off-by: Heiko Stuebner <heiko@sntech.de>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/62d0e71df063101e4551327bd9fa9aaa3535c86b"},{"sha":"4dc0dd83603f05dc3ae152af33ecb15104c313f3","author":{"name":"Tomeu Vizoso","email":"05836fa86782885b94fac1506837be15b63cb13f@collabora.com"},"message":"spi: rockchip: Signal unfinished DMA transfers\n\nWhen using DMA, the transfer_one callback should return 1 because the\ntransfer hasn't finished yet.\n\nA previous commit changed the function to return 0 when the DMA channels\nwere correctly prepared.\n\nThis manifested in Veyron boards with this message:\n\n[ 1.983605] cros-ec-spi spi0.0: EC failed to respond in time\n\nFixes: ea9849113343 (\"spi: rockchip: check return value of dmaengine_prep_slave_sg\")\nSigned-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nCc: stable@vger.kernel.org","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/4dc0dd83603f05dc3ae152af33ecb15104c313f3"},{"sha":"6e85dbe4b461e59fa3cad6f6235cb47fa4c6a629","author":{"name":"Crestez Dan Leonard","email":"f419bffefded4052ada67fd74a3c84ecc7fbe630@intel.com"},"message":"iio: inv_mpu6050: Fix use-after-free in ACPI code\n\nIn some cases this can result in incorrectly returning a negative value\nfrom asus_acpi_get_sensor_info and the AK8963 magnetometer failing to\nshow up.\n\nNote cpm is an alias for buffer.pointer which isn't apparent in this\npatch on it's own.\n\nCc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>\nSigned-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>\nAcked-by: Daniel Baluta <daniel.baluta@intel.com>\nSigned-off-by: Jonathan Cameron <jic23@kernel.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/6e85dbe4b461e59fa3cad6f6235cb47fa4c6a629"},{"sha":"7e982555d89cc84b1fa23b5d54c7ffd9f7753908","author":{"name":"Arnd Bergmann","email":"72a0f6d3b182607e6d5c44b93e1abb7b23ee18f3@arndb.de"},"message":"staging: iio: fix ad7606_spi regression\n\nAs pointed out by Geert Uytterhoeven, the patch was incorrect\nand breaks the driver, which was fortunately pointed out by\nthis gcc warning:\n\ndrivers/staging/iio/adc/ad7606_spi.c: In function ‘ad7606_spi_read_block’:\ndrivers/staging/iio/adc/ad7606_spi.c:34: warning: ‘data’ is used uninitialized in this function\n\nThe effect of the patch is that the data is copied into\na random memory location (from the uninitialized pointer)\ninstead of being byteswapped in place.\n\nThis adds the initialization for the 'data' variable back\nto restore the original behavior.\n\nCc: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>\nFixes: 87787e5ef727 (\"Staging: iio: Fix sparse endian warning\")\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nAcked-by: Geert Uytterhoeven <geert@linux-m68k.org>\nSigned-off-by: Jonathan Cameron <jic23@kernel.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/7e982555d89cc84b1fa23b5d54c7ffd9f7753908"},{"sha":"f4070a19142d5ee06f0da0cef56a0e78995f172c","author":{"name":"Luis de Bethencourt","email":"9efc00209c16d128d4805749ca5906d62f798307@osg.samsung.com"},"message":"staging: iio: ad5933: fix order of cycle conditions\n\nCorrectly handle the settling time cycles value. The else branch is an\nimpossible condition, > 1022 in the else branch of > 511. Flipping the order.\n\nBased on the Table 13 at the bottom of Page 25 of the Data Sheet:\nhttp://www.analog.com/media/en/technical-documentation/data-sheets/AD5933.pdf\n\nSigned-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>\nReviewed-by: Lars-Peter Clausen <lars@metafoo.de>\nSigned-off-by: Jonathan Cameron <jic23@kernel.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/f4070a19142d5ee06f0da0cef56a0e78995f172c"},{"sha":"ea1d39a31d3b1b6060b6e83e5a29c069a124c68a","author":{"name":"Oscar","email":"9512c3e05899517c1c4f88f7e4aab81c7a9c7a0a@naiandei.net"},"message":"usb: common: otg-fsm: add license to usb-otg-fsm\n\nFix warning about tainted kernel because usb-otg-fsm has no license.\nWARNING: with this patch usb-otg-fsm module can be loaded\nbut then the kernel will hang. Tested with a udoo quad board.\n\nCc: <stable@vger.kernel.org> #v4.1+\nSigned-off-by: Oscar <oscar@naiandei.net>\nSigned-off-by: Peter Chen <peter.chen@nxp.com>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/ea1d39a31d3b1b6060b6e83e5a29c069a124c68a"},{"sha":"6d9fe44bd73d567d04d3a68a2d2fa521ab9532f2","author":{"name":"Michal Suchanek","email":"82b4e4cb51c00602fe6bc2bbc2c157daa28b449f@gmail.com"},"message":"spi: sun4i: fix FIFO limit\n\nWhen testing SPI without DMA I noticed that filling the FIFO on the\nspi controller causes timeout.\n\nAlways leave room for one byte in the FIFO.\n\nSigned-off-by: Michal Suchanek <hramrach@gmail.com>\nAcked-by: Maxime Ripard <maxime.ripard@free-electrons.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nCc: stable@vger.kernel.org","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/6d9fe44bd73d567d04d3a68a2d2fa521ab9532f2"},{"sha":"719bd6542044efd9b338a53dba1bef45f40ca169","author":{"name":"Michal Suchanek","email":"82b4e4cb51c00602fe6bc2bbc2c157daa28b449f@gmail.com"},"message":"spi: sunxi: fix transfer timeout\n\nThe trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over\n1MHz SPI bus takes way longer than that. Calculate the timeout from the\nactual time the transfer is supposed to take and multiply by 2 for good\nmeasure.\n\nSigned-off-by: Michal Suchanek <hramrach@gmail.com>\nAcked-by: Maxime Ripard <maxime.ripard@free-electrons.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nCc: stable@vger.kernel.org","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/719bd6542044efd9b338a53dba1bef45f40ca169"},{"sha":"8a092e682f20f193f2070dba2ea1904e95814126","author":{"name":"Mika Båtsman","email":"4cb52ccfb6d3e4c5502adad5cd6e4dece8a74425@mvista.com"},"message":"regulator: anatop: allow regulator to be in bypass mode\n\nBypass support was added in commit d38018f2019c (\"regulator: anatop: Add\nbypass support to digital LDOs\"). A check for valid voltage selectors was\nadded in commit da0607c8df5c (\"regulator: anatop: Fail on invalid voltage\nselector\") but it also discards all regulators that are in bypass mode. Add\ncheck for the bypass setting. Errors below were seen on a Variscite mx6\nboard.\n\nanatop_regulator 20c8000.anatop:regulator-vddcore@140: Failed to read a valid default voltage selector.\nanatop_regulator: probe of 20c8000.anatop:regulator-vddcore@140 failed with error -22\nanatop_regulator 20c8000.anatop:regulator-vddsoc@140: Failed to read a valid default voltage selector.\nanatop_regulator: probe of 20c8000.anatop:regulator-vddsoc@140 failed with error -22\n\nFixes: da0607c8df5c (\"regulator: anatop: Fail on invalid voltage selector\")\nSigned-off-by: Mika Båtsman <mbatsman@mvista.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/8a092e682f20f193f2070dba2ea1904e95814126"},{"sha":"6762925df4642aec5629f7971ba477d6930f53f7","author":{"name":"Yoshihiro Shimoda","email":"806084c42fbad0778b005fdc6faa04d57cfdf777@renesas.com"},"message":"phy: rcar-gen3-usb2: fix unexpected repeat interrupts of VBUS change\n\nThis patch fixes an issue that the driver is possible to cause\nunexpected repeat interrupts if a board condition is wrong\n(e.g. even if the ID pin is as function, a board supplies the VBUS.)\n\nThe reason why unexpected repeat interrupts happen is:\n 1) The driver changed the mode to function if it detected the ID pin\n    is high and the VBUS is high.\n 2) After the driver changed function mode, it disabled the \"VBUS control\"\n    feature. Then, the VBUS signal will be low.\n 3) Since the VBUS change interruption happened, the driver checked\n    the ID pin and VBUS.\n 4) Since VBUS was low, the driver changed the mode to host and enabled\n    the \"VBUS control\" feature. Then the VBUS signal will be high.\n 5) Since the VBUS change interruption happened, the driver did 1) above.\n\nSo, this patch modified the condition in rcar_gen3_device_recognition()\nto check the ID pin only.\n\nFixes: 1114e2d (phy: rcar-gen3-usb2: change the mode to OTG on the combined channel)\nCc: <stable@vger.kernel.org> # v4.5+\nReported-by: Simon Horman <horms@verge.net.au>\nSigned-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>\nSigned-off-by: Kishon Vijay Abraham I <kishon@ti.com>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/6762925df4642aec5629f7971ba477d6930f53f7"},{"sha":"075adb8046532d9642f411a92b4f385d04ced24d","author":{"name":"Wei Yongjun","email":"07c9053292b1ab0fc7bfece763550eb7eb3e7a18@trendmicro.com.cn"},"message":"phy: rockchip-dp: fix return value check in rockchip_dp_phy_probe()\n\nIn case of error, the function devm_kzalloc() returns NULL pointer\nnot ERR_PTR(). The IS_ERR() test in the return value check should\nbe replaced with NULL test.\n\nSigned-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>\nReviewed-by: Heiko Stuebner <heiko@sntech.de>\nSigned-off-by: Kishon Vijay Abraham I <kishon@ti.com>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/075adb8046532d9642f411a92b4f385d04ced24d"},{"sha":"5cf700ac9d50353dc5b8194a57c6f40bf1fc4424","author":{"name":"Quentin Schulz","email":"d8b6d84dc4895f5f7aa417a44cabc5d13c4bd844@free-electrons.com"},"message":"phy: phy-sun4i-usb: Fix optional gpios failing probe\n\nThe interrupt 0 is not a valid interrupt number. In the event where the\nretrieval of the vbus-det gpio would return null, the gpiod_to_irq\ncallback would return 0, while the current code makes the assumption\nthat it is a valid interrupt, and would go on calling request_irq.\nObviously, this would fail, preventing the driver from probing properly,\nwhile the vbus and id gpios are optional.\n\nSigned-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>\nSigned-off-by: Kishon Vijay Abraham I <kishon@ti.com>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/5cf700ac9d50353dc5b8194a57c6f40bf1fc4424"},{"sha":"d99cb37828a2fe344ecc95d1fad570bbe447cc06","author":{"name":"Ben Dooks","email":"c972f865a0703589f2f97625987b68b364737473@codethink.co.uk"},"message":"phy-sun4i-usb: fix missing __iomem *\n\nFix the missing __iomem attribute in sun4i_usb_phy_write()\nfunction. This fixes the following sparse warnings:\n\ndrivers/phy/phy-sun4i-usb.c:178:39: warning: incorrect type in initializer (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:178:39:    expected void *phyctl\ndrivers/phy/phy-sun4i-usb.c:178:39:    got void [noderef] <asn:2>*\ndrivers/phy/phy-sun4i-usb.c:185:17: warning: incorrect type in argument 2 (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:185:17:    expected void volatile [noderef] <asn:2>*addr\ndrivers/phy/phy-sun4i-usb.c:185:17:    got void *phyctl\ndrivers/phy/phy-sun4i-usb.c:189:24: warning: incorrect type in argument 1 (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:189:24:    expected void const volatile [noderef] <asn:2>*addr\ndrivers/phy/phy-sun4i-usb.c:189:24:    got void *phyctl\ndrivers/phy/phy-sun4i-usb.c:196:17: warning: incorrect type in argument 2 (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:196:17:    expected void volatile [noderef] <asn:2>*addr\ndrivers/phy/phy-sun4i-usb.c:196:17:    got void *phyctl\ndrivers/phy/phy-sun4i-usb.c:199:24: warning: incorrect type in argument 1 (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:199:24:    expected void const volatile [noderef] <asn:2>*addr\ndrivers/phy/phy-sun4i-usb.c:199:24:    got void *phyctl\ndrivers/phy/phy-sun4i-usb.c:205:17: warning: incorrect type in argument 2 (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:205:17:    expected void volatile [noderef] <asn:2>*addr\ndrivers/phy/phy-sun4i-usb.c:205:17:    got void *phyctl\ndrivers/phy/phy-sun4i-usb.c:208:24: warning: incorrect type in argument 1 (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:208:24:    expected void const volatile [noderef] <asn:2>*addr\ndrivers/phy/phy-sun4i-usb.c:208:24:    got void *phyctl\ndrivers/phy/phy-sun4i-usb.c:210:17: warning: incorrect type in argument 2 (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:210:17:    expected void volatile [noderef] <asn:2>*addr\ndrivers/phy/phy-sun4i-usb.c:210:17:    got void *phyctl\ndrivers/phy/phy-sun4i-usb.c:212:24: warning: incorrect type in argument 1 (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:212:24:    expected void const volatile [noderef] <asn:2>*addr\ndrivers/phy/phy-sun4i-usb.c:212:24:    got void *phyctl\ndrivers/phy/phy-sun4i-usb.c:214:17: warning: incorrect type in argument 2 (different address spaces)\ndrivers/phy/phy-sun4i-usb.c:214:17:    expected void volatile [noderef] <asn:2>*addr\ndrivers/phy/phy-sun4i-usb.c:214:17:    got void *phyctl\n\nSigned-off-by: Ben Dooks <ben.dooks@codethink.co.uk>\nAcked-by: Hans de Goede <hdegoede@redhat.com>\nSigned-off-by: Kishon Vijay Abraham I <kishon@ti.com>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/d99cb37828a2fe344ecc95d1fad570bbe447cc06"}]}
{"actor":{"display_login":"Jackeagle"}}