- 25 Feb, 2016 40 commits
-
-
Tony Lindgren authored
commit 4da597d1 upstream. We don't want to write to .text so let's move ppa_zero_params and ppa_por_params to .data and access them via pointers. Note that I have not been able to test as we I don't have a HS omap4 to test with. The code has been changed in similar way as for omap3 though. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
Nicolas Pitre <nico@linaro.org> Fixes: 1e6b4811 ("ARM: mm: allow non-text sections to be non-executable") Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tony Lindgren authored
commit a5311d4d upstream. We don't want to write to .text and we can move save_secure_ram_context into .data as it all gets copied into SRAM anyways. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
-
Tony Lindgren authored
commit eeaf9646 upstream. We don't want to write to .text section. Let's move l2dis_3630 to .data and access it via a pointer. For calculating the offset, let's optimize out the add and do it in ldr/str as suggested by Nicolas Pitre <nicolas.pitre@linaro.org>. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
-
Tony Lindgren authored
commit 0a0b1327 upstream. We don't want to write to .text, so let's move l2_inv_api_params to .data and access it via a pointer. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
-
Tony Lindgren authored
commit d9db5910 upstream. We don't want to be writing to .text so it can be set rodata. Fix error "Unable to handle kernel paging request at virtual address c012396c" in wait_dll_lock_timed if CONFIG_DEBUG_RODATA is selected. As these counters are for debugging only and unused, we can just remove them. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
-
Wenyou Yang authored
commit aae6b18f upstream. On SAMA5D4EK board, the Ethernet doesn't work after resuming from the suspend state. Signed-off-by:
Wenyou Yang <wenyou.yang@atmel.com> [nicolas.ferre@atmel.com: adapt to newer kernel] Fixes: 38153a01 ("ARM: at91/dt: sama5d4: add dts for sama5d4 xplained board") Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Nicolas Ferre authored
commit e873cc02 upstream. For phy0 KSZ8081, the type of GPIO IRQ should be "level low" instead of "edge falling". Signed-off-by:
-
Mohamed Jamsheeth Hajanajubudeen authored
commit 929e883f upstream. Change instance id of DBGU to 45. Signed-off-by:
Mohamed Jamsheeth Hajanajubudeen <mohamedjamsheeth.hajanajubudeen@atmel.com> Fixes: 7c661394 ("ARM: at91: dt: add device tree file for SAMA5D4 SoC") Signed-off-by:
-
Alexandre Belloni authored
commit f505dba7 upstream. No interrupt were received from the phy because PIOE 1 may not be properly muxed. It prevented proper link detection, especially since commit 321beec5 ("net: phy: Use interrupts when available in NOLINK state") disables polling. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
H. Nikolaus Schaller authored
commit c08659d4 upstream. tested on OMP5432 EVM Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by:
-
Tony Lindgren authored
commit af756bbc upstream. The palmas PMIC has two control lines that need to be muxed properly for things to work. The sys_nirq pin is used for interrupts, and msecure pin is used for enabling writes to some PMIC registers. Without these pins configured properly things can fail in mysterious ways. For example, we can't update the RTC registers on palmas PMIC unless the msecure pin is configured. And this is probably the reason why we had RTC missing from the omap5 dts file. According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)" swps052f.pdf, mux mode 1 is for sys_drm_msecure so in theory there's should be no need to configure it as a GPIO pin. However, it seems there are some reliability issues using the msecure mux mode. And the TI trees configure the msecure pin as GPIO out high instead. As the PMIC only cares that the msecure line is high to allow access to the RTC registers, let's use a GPIO hog as suggested by Nishanth Menon <nm@ti.com>. Also the use of the internal pull was considered but supposedly that may not be capable of keeping the line high in a noisy environment. If we ever see high security omap5 products in the mainline tree, those need to skip the msecure pin muxing and ignore setting the GPIO hog. Chances are the related pin mux registers are locked in that case and the msecure pin is managed by whatever software may be running in the ARM TrustZone. Who knows what the original intention of the msecure pin was. Maybe it was supposed to prevent the system time to be set back for some game demo modes to time out? Anyways, it seems that later PMICs like tps659037 have recycled this pin for "powerhold" and devices like beagle-x15 do not need changes to the msecure pin configuration. To avoid further confusion with TWL variant PMICs, beagle-x15 does not have a back-up battery for RTC palmas. Instead the mcp79410 RTC is used with rtc-ds1307 driver. There is a "powerhold" jumper j5 holes near the palmas PMIC, and shorting it seems to power up beagle-x15 automatically. It is unknown if it also has other side effects to the beagle-x15 power up sequence. Signed-off-by:
-
Adam Ford authored
commit 0ea24daa upstream. The tcxo-clock-frequency binding is listed as optional, but without it the wl12xx used on the torpedo + wireless may hang. Scanning also appears broken without this patch. Signed-off-by:
Adam Ford <aford173@gmail.com> Fixes: 687c2767 ("ARM: dts: Add minimal support for LogicPD Torpedo DM3730 devkit") Signed-off-by:
-
Linus Walleij authored
commit 418d5516 upstream. The DTSI file for the Nomadik does not properly specify how the PL180 levelshifter is connected: the Nomadik actually needs all the five st,sig-dir-* flags set to properly control all lines out. Further this board supports full power cycling of the card, and since this variant has no hardware clock gating, it needs a ridiculously low frequency setting to keep up with the ever overflowing FIFO. The pin configuration set-up is a bit of a mystery, because of course these pins are a mix of inputs and outputs. However the reference implementation sets all pins to "output" with unspecified initial value, so let's do that here as well. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Linus Walleij authored
commit 5070fb14 upstream. When trying to set the ICST 307 clock to 25174000 Hz I ran into this arithmetic error: the icst_hz_to_vco() correctly figure out DIVIDE=2, RDW=100 and VDW=99 yielding a frequency of 25174000 Hz out of the VCO. (I replicated the icst_hz() function in a spreadsheet to verify this.) However, when I called icst_hz() on these VCO settings it would instead return 4122709 Hz. This causes an error in the common clock driver for ICST as the common clock framework will call .round_rate() on the clock which will utilize icst_hz_to_vco() followed by icst_hz() suggesting the erroneous frequency, and then the clock gets set to this. The error did not manifest in the old clock framework since this high frequency was only used by the CLCD, which calls clk_set_rate() without first calling clk_round_rate() and since the old clock framework would not call clk_round_rate() before setting the frequency, the correct values propagated into the VCO. After some experimenting I figured out that it was due to a simple arithmetic overflow: the divisor for 24Mhz reference frequency as reference becomes 24000000*2*(99+8)=0x132212400 and the "1" in bit 32 overflows and is lost. But introducing an explicit 64-by-32 bit do_div() and casting the divisor into (u64) we get the right frequency back, and the right frequency gets set. Tested on the ARM Versatile. Cc: linux-clk@vger.kernel.org Cc: Pawel Moll <pawel.moll@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Linus Walleij authored
commit e972c374 upstream. Since the dawn of time the ICST code has only supported divide by one or hang in an eternal loop. Luckily we were always dividing by one because the reference frequency for the systems using the ICSTs is 24MHz and the [min,max] values for the PLL input if [10,320] MHz for ICST307 and [6,200] for ICST525, so the loop will always terminate immediately without assigning any divisor for the reference frequency. But for the code to make sense, let's insert the missing i++ Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
-
Mika Penttilä authored
commit 57adec86 upstream. Calling apply_to_page_range with an empty range results in a BUG_ON from the core code. This can be triggered by trying to load the st_drv module with CONFIG_DEBUG_SET_MODULE_RONX enabled: kernel BUG at mm/memory.c:1874! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 1764 Comm: insmod Not tainted 4.5.0-rc1+ #2 Hardware name: ARM Juno development board (r0) (DT) task: ffffffc9763b8000 ti: ffffffc975af8000 task.ti: ffffffc975af8000 PC is at apply_to_page_range+0x2cc/0x2d0 LR is at change_memory_common+0x80/0x108 This patch fixes the issue by making change_memory_common (called by the set_memory_* functions) a NOP when numpages == 0, therefore avoiding the erroneous call to apply_to_page_range and bringing us into line with x86 and s390. Reviewed-by:
Laura Abbott <labbott@redhat.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Mika Penttilä <mika.penttila@nextfour.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Thomas Petazzoni authored
commit 079ae0c1 upstream. The Armada 388 GP Device Tree file describes two times a regulator named 'reg_usb2_1_vbus', with the exact same description. This has been wrong since Armada 388 GP support was introduced. Fixes: 928413bd ("ARM: mvebu: Add Armada 388 General Purpose Development Board support") Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Alexey Kardashevskiy authored
commit 6ecad912 upstream. Quite often drivers set only "write" permission assuming that this includes "read" permission as well and this works on plenty of platforms. However IODA2 is strict about this and produces an EEH when "read" permission is not set and reading happens. This adds a workaround in the IODA code to always add the "read" bit when the "write" bit is set. Fixes: 10b35b2b ("powerpc/powernv: Do not set "read" flag if direction==DMA_NONE") Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Tested-by:
Douglas Miller <dougmill@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Gavin Shan authored
commit 1bc74f1c upstream. When PCI bus is unplugged during full hotplug for EEH recovery, the platform PE instance (struct pnv_ioda_pe) isn't released and it dereferences the stale PCI bus that has been released. It leads to kernel crash when referring to the stale PCI bus. This fixes the issue by correcting the PE's primary bus when it's oneline at plugging time, in pnv_pci_dma_bus_setup() which is to be called by pcibios_fixup_bus(). Reported-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reported-by:
Pradipta Ghosh <pradghos@in.ibm.com> Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Tested-by:
-
Gavin Shan authored
commit 05ba75f8 upstream. When PE is created, its primary bus is cached to pe->bus. At later point, the cached primary bus is returned from eeh_pe_bus_get(). However, we could get stale cached primary bus and run into kernel crash in one case: full hotplug as part of fenced PHB error recovery releases all PCI busses under the PHB at unplugging time and recreate them at plugging time. pe->bus is still dereferencing the PCI bus that was released. This adds another PE flag (EEH_PE_PRI_BUS) to represent the validity of pe->bus. pe->bus is updated when its first child EEH device is online and the flag is set. Before unplugging in full hotplug for error recovery, the flag is cleared. Fixes: 8cdb2833 ("powerpc/eeh: Trace PCI bus from PE") Reported-by:
-
Gavin Shan authored
commit 7e56f627 upstream. In eeh_pe_loc_get(), the PE location code is retrieved from the "ibm,loc-code" property of the device node for the bridge of the PE's primary bus. It's not correct because the property indicates the parent PE's location code. This reads the correct PE location code from "ibm,io-base-loc-code" or "ibm,slot-location-code" property of PE parent bus's device node. Fixes: 357b2f3d ("powerpc/eeh: Dump PE location code") Signed-off-by:
Russell Currey <ruscur@russell.cc> Signed-off-by:
-
Trond Myklebust authored
commit 13331a55 upstream. We're seeing hangs in the NFS client code, with loops of the form: RPC: 30317 xmit incomplete (267368 left of 524448) RPC: 30317 call_status (status -11) RPC: 30317 call_transmit (status 0) RPC: 30317 xprt_prepare_transmit RPC: 30317 xprt_transmit(524448) RPC: xs_tcp_send_request(267368) = -11 RPC: 30317 xmit incomplete (267368 left of 524448) RPC: 30317 call_status (status -11) RPC: 30317 call_transmit (status 0) RPC: 30317 xprt_prepare_transmit RPC: 30317 xprt_transmit(524448) Turns out commit ceb5d58b ("net: fix sock_wake_async() rcu protection") moved SOCKWQ_ASYNC_NOSPACE out of sock->flags and into sk->sk_wq->flags, however it never tried to fix up the code in net/sunrpc. The new idiom is to use the flags in the RCU protected struct socket_wq. While we're at it, clear out the now redundant places where we set/clear SOCKWQ_ASYNC_NOSPACE and SOCK_NOSPACE. In principle, sk_stream_wait_memory() is supposed to set these for us, so we only need to clear them in the particular case of our ->write_space() callback. Fixes: ceb5d58b ("net: fix sock_wake_async() rcu protection") Cc: Eric Dumazet <edumazet@google.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Andrew Gabbasov authored
commit bb00c898 upstream. If a name contains at least some characters with Unicode values exceeding single byte, the CS0 output should have 2 bytes per character. And if other input characters have single byte Unicode values, then the single input byte is converted to 2 output bytes, and the length of output becomes larger than the length of input. And if the input name is long enough, the output length may exceed the allocated buffer length. All this means that conversion from UTF8 or NLS to CS0 requires checking of output length in order to stop when it exceeds the given output buffer size. [JK: Make code return -ENAMETOOLONG instead of silently truncating the name] Signed-off-by:
Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Andrew Gabbasov authored
commit ad402b26 upstream. udf_CS0toUTF8 function stops the conversion when the output buffer length reaches UDF_NAME_LEN-2, which is correct maximum name length, but, when checking, it leaves the space for a single byte only, while multi-bytes output characters can take more space, causing buffer overflow. Similar error exists in udf_CS0toNLS function, that restricts the output length to UDF_NAME_LEN, while actual maximum allowed length is UDF_NAME_LEN-2. In these cases the output can override not only the current buffer length field, causing corruption of the name buffer itself, but also following allocation structures, causing kernel crash. Adjust the output length checks in both functions to prevent buffer overruns in case of multi-bytes UTF8 or NLS characters. Signed-off-by:
-
Vegard Nossum authored
commit b0918d9f upstream. udf_next_aext() just follows extent pointers while extents are marked as indirect. This can loop forever for corrupted filesystem. Limit number the of indirect extents we are willing to follow in a row. [JK: Updated changelog, limit, style] Signed-off-by:
Vegard Nossum <vegard.nossum@oracle.com> Cc: Jan Kara <jack@suse.com> Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Trond Myklebust authored
commit 082fa37d upstream. We must not skip encoding the statistics, or the server will see an XDR encoding error. Signed-off-by:
-
Andrew Elble authored
commit 361cad3c upstream. We've seen this in a packet capture - I've intermixed what I think was going on. The fix here is to grab the so_lock sooner. 1964379 -> #1 open (for write) reply seqid=1 1964393 -> #2 open (for read) reply seqid=2 __nfs4_close(), state->n_wronly-- nfs4_state_set_mode_locked(), changes state->state = [R] state->flags is [RW] state->state is [R], state->n_wronly == 0, state->n_rdonly == 1 1964398 -> #3 open (for write) call -> because close is already running 1964399 -> downgrade (to read) call seqid=2 (close of #1) 1964402 -> #3 open (for write) reply seqid=3 __update_open_stateid() nfs_set_open_stateid_locked(), changes state->flags state->flags is [RW] state->state is [R], state->n_wronly == 0, state->n_rdonly == 1 new sequence number is exposed now via nfs4_stateid_copy() next step would be update_open_stateflags(), pending so_lock 1964403 -> downgrade reply seqid=2, fails with OLD_STATEID (close of #1) nfs4_close_prepare() gets so_lock and recalcs flags -> send close 1964405 -> downgrade (to read) call seqid=3 (close of #1 retry) __update_open_stateid() gets so_lock * update_open_stateflags() updates state->n_wronly. nfs4_state_set_mode_locked() updates state->state state->flags is [RW] state->state is [RW], state->n_wronly == 1, state->n_rdonly == 1 * should have suppressed the preceding nfs4_close_prepare() from sending open_downgrade 1964406 -> write call 1964408 -> downgrade (to read) reply seqid=4 (close of #1 retry) nfs_clear_open_stateid_locked() state->flags is [R] state->state is [RW], state->n_wronly == 1, state->n_rdonly == 1 1964409 -> write reply (fails, openmode) Signed-off-by:
Andrew Elble <aweits@rit.edu> Signed-off-by:
-
Trond Myklebust authored
commit 86fb449b upstream. Jeff reports seeing an Oops in ff_layout_alloc_lseg. Turns out copy+paste has played cruel tricks on a nested loop. Reported-by:
Jeff Layton <jeff.layton@primarydata.com> Signed-off-by:
-
Trond Myklebust authored
commit ade14a7d upstream. If a NFSv4 client uses the cache_consistency_bitmask in order to request only information about the change attribute, timestamps and size, then it has not revalidated all attributes, and hence the attribute timeout timestamp should not be updated. Reported-by:
Donald Buczek <buczek@molgen.mpg.de> Signed-off-by:
-
Anton Protopopov authored
commit 4b550af5 upstream. The setup_ntlmv2_rsp() function may return positive value ENOMEM instead of -ENOMEM in case of kmalloc failure. Signed-off-by:
Anton Protopopov <a.s.protopopov@gmail.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Vasily Averin authored
commit 01b9b0b2 upstream. In some cases tmp_bug can be not filled in cifs_filldir and stay uninitialized, therefore its printk with "%s" modifier can leak content of kernelspace memory. If old content of this buffer does not contain '\0' access bejond end of allocated object can crash the host. Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
Steve French <sfrench@localhost.localdomain> Signed-off-by:
-
Rabin Vincent authored
commit 820962dc upstream. cifs_call_async() queues the MID to the pending list and calls smb_send_rqst(). If smb_send_rqst() performs a partial send, it sets the tcpStatus to CifsNeedReconnect and returns an error code to cifs_call_async(). In this case, cifs_call_async() removes the MID from the list and returns to the caller. However, cifs_call_async() releases the server mutex _before_ removing the MID. This means that a cifs_reconnect() can race with this function and manage to remove the MID from the list and delete the entry before cifs_call_async() calls cifs_delete_mid(). This leads to various crashes due to the use after free in cifs_delete_mid(). Task1 Task2 cifs_call_async(): - rc = -EAGAIN - mutex_unlock(srv_mutex) cifs_reconnect(): - mutex_lock(srv_mutex) - mutex_unlock(srv_mutex) - list_delete(mid) - mid->callback() cifs_writev_callback(): - mutex_lock(srv_mutex) - delete(mid) - mutex_unlock(srv_mutex) - cifs_delete_mid(mid) <---- use after free Fix this by removing the MID in cifs_call_async() before releasing the srv_mutex. Also hold the srv_mutex in cifs_reconnect() until the MIDs are moved out of the pending list. Signed-off-by:
Rabin Vincent <rabin.vincent@axis.com> Acked-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by:
-
Jamie Bainbridge authored
commit ec7147a9 upstream. Under some conditions, CIFS can repeatedly call the cifs_dbg() logging wrapper. If done rapidly enough, the console framebuffer can softlockup or "rcu_sched self-detected stall". Apply the built-in log ratelimiters to prevent such hangs. Signed-off-by:
Jamie Bainbridge <jamie.bainbridge@gmail.com> Signed-off-by:
-
Dan Carpenter authored
commit d81dac3c upstream. In twl4030_bci_probe() there are some failure paths where we call iio_channel_release() with a NULL pointer. (Apparently, that driver can opperate without a valid channel pointer). Let's fix it by adding a NULL check in iio_channel_release(). Fixes: 2202e1fc ('drivers: power: twl4030_charger: fix link problems when building as module') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Akinobu Mita authored
commit 431386e7 upstream. According to the datasheet, the resolusion of temperature sensor is -5.35 counts/C. Temperature ADC is 472 counts at 25C. (https://www.sparkfun.com/datasheets/Sensors/Pressure/MPL115A1.pdf NOTE: This is older revision, but this information is removed from the latest datasheet from nxp somehow) Temp [C] = (Tadc - 472) / -5.35 + 25 = (Tadc - 605.750000) * -0.186915888 So the correct offset is -605.750000. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by:
-
Gabriele Mazzotta authored
commit fa34e6dd upstream. As per the ACPI specification (Revision 5.0) [1], the data coming from the sensor represent the ambient light illuminance reading expressed in lux. So use IIO_CHAN_INFO_PROCESSED to signify that the data are pre-processed. However, to keep backward ABI compatibility, the IIO_CHAN_INFO_RAW bit is not removed. [1] http://www.acpi.info/DOWNLOADS/ACPIspec50.pdf This issue has also been responsible for at least one userspace bug report hence marking what is a small semantic fix really for stable. [2] https://github.com/hadess/iio-sensor-proxy/issues/46Signed-off-by:
Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by:
-
Yong Li authored
commit 97a249e9 upstream. Without this change, the name entity for mcp4725 is missing in /sys/bus/iio/devices/iio\:device*/name With this change, name is reported correctly Signed-off-by:
Yong Li <sdliyong@gmail.com> Signed-off-by:
-
Vegard Nossum authored
commit 01cc5235 upstream. Ran into this on UML: drivers/iio/accel/stk8ba50.c: In function ‘stk8ba50_data_rdy_trigger_set_state’: drivers/iio/accel/stk8ba50.c:163:9: error: implicit declaration of function ‘iio_trigger_get_drvdata’ [-Werror=implicit-function-declaration] iio_trigger_get_drvdata() is defined only when IIO_TRIGGER is selected. Signed-off-by:
-
Vegard Nossum authored
commit 005ce071 upstream. Ran into this on UML: drivers/built-in.o: In function `vf610_adc_probe': drivers/iio/adc/vf610_adc.c:744: undefined reference to `devm_ioremap_resource' devm_ioremap_resource() is defined only when HAS_IOMEM is selected. Signed-off-by:
-
Markus Elfring authored
commit c08ae185 upstream. The return type "unsigned int" was used by the ltr501_match_samp_freq() function despite of the aspect that it will eventually return a negative error code. Improve this implementation detail by deletion of the type modifier then. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Acked-by:
-
