- 28 May, 2015 22 commits
-
-
Martin K. Petersen authored
commit 9a9324d3 upstream. The queued TRIM problems appear to be generic to Samsung's firmware and not tied to a particular model. A recent update to the 840 EVO firmware introduced the same issue as we saw on 850 Pro. Blacklist queued TRIM on all 800-series drives while we work this issue with Samsung. Reported-by:
Günter Waller <g.wal@web.de> Reported-by:
Sven Köhler <sven.koehler@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Tejun Heo <tj@kernel.org> [ luis: backported to 3.16: - adjusted context - drop ZERO_AFTER_TRIM flag ] Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Martin K. Petersen authored
commit 6fc4d97a upstream. Blacklist queued TRIM on this drive for now. Reported-by:
Stefan Keller <linux-list@zahlenfresser.de> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Martin K. Petersen authored
commit ff7f53fb upstream. Micron has released an updated firmware (MU02) for M510/M550/MX100 drives to fix the issues with queued TRIM. Queued TRIM remains broken on M500 but is working fine on later drives such as M600 and MX200. Tweak our blacklist to reflect the above. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71371Signed-off-by:
-
Scott Mayhew authored
commit 9507271d upstream. In an environment where the KDC is running Active Directory, the exported composite name field returned in the context could be large enough to span a page boundary. Attaching a scratch buffer to the decoding xdr_stream helps deal with those cases. The case where we saw this was actually due to behavior that's been fixed in newer gss-proxy versions, but we're fixing it here too. Signed-off-by:
Scott Mayhew <smayhew@redhat.com> Reviewed-by:
Simo Sorce <simo@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Christoph Hellwig authored
commit ebe9cb3b upstream. If we find a non-confirmed openowner we jump to exit the function, but do not set an error value. Fix this by factoring out a helper to do the check and properly set the error from nfsd4_validate_stateid. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Jeppe Ledet-Pedersen authored
commit 5793affe upstream. Using IDR_SRR in RXFIFO_ID to test for the presence of data is only valid for standard frames. For extended frames the bit is always 1 and IDR_RTR should be used instead. This patch switches the check to use CAN_RTR_FLAG which is correctly set when reading the ID. The patch also changes the DW1/DW2 to be read unconditionally, since this is necessary to remove the frame from the RXFIFO. Signed-off-by:
Jeppe Ledet-Pedersen <jlp@gomspace.com> Acked-by:
Kedareswara rao Appana <appanad@xilinx.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Jason A. Donenfeld authored
commit 82ee3aeb upstream. Samsung has just released a portable USB3 SSD, coming in a very small and nice form factor. It's USB ID is 04e8:8001, which unfortunately is already used by the Palm Visor driver for the Samsung I330 phone cradle. Having pl2303 or visor pick up this device ID results in conflicts with the usb-storage driver, which handles the newly released portable USB3 SSD. To work around this conflict, I've dug up a mailing list post [1] from a long time ago, in which a user posts the full USB descriptor information. The most specific value in this appears to be the interface class, which has value 255 (0xff). Since usb-storage requires an interface class of 0x8, I believe it's correct to disambiguate the two devices by matching on 0xff inside visor. [1] http://permalink.gmane.org/gmane.linux.usb.user/4264Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Jason A. Donenfeld authored
commit 48ef23a4 upstream. This phone is already supported by the visor driver. Signed-off-by:
-
Mark Edwards authored
commit c735ed74 upstream. Added the USB serial console device ID for KCF Technologies PRN device which has a USB port for its serial console. Signed-off-by:
Mark Edwards <sonofaforester@gmail.com> Signed-off-by:
-
Larry Finger authored
commit 414b7e3b upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to usb_control_msg() with a timeout value of 0. In some instances where the interface is shutting down, this infinite wait results in a CPU deadlock. A one second timeout fixes this problem without affecting any normal operations. This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786. Reported-by:
Bernhard Wiedemann <bwiedemann@suse.com> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Bernhard Wiedemann <bwiedemann@suse.com> Cc: Takashi Iwai<tiwai@suse.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Krzysztof Opasiak authored
commit 903124fe upstream. memset() to 0 interfaces array before reusing usb_configuration structure. This commit fix bug: ln -s functions/acm.1 configs/c.1 ln -s functions/acm.2 configs/c.1 ln -s functions/acm.3 configs/c.1 echo "UDC name" > UDC echo "" > UDC rm configs/c.1/acm.* rmdir functions/* mkdir functions/ecm.usb0 ln -s functions/ecm.usb0 configs/c.1 echo "UDC name" > UDC [ 82.220969] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 82.229009] pgd = c0004000 [ 82.231698] [00000000] *pgd=00000000 [ 82.235260] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 82.240638] Modules linked in: [ 82.243681] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.0.0-rc2 #39 [ 82.249926] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 82.256003] task: c07cd2f0 ti: c07c8000 task.ti: c07c8000 [ 82.261393] PC is at composite_setup+0xe3c/0x1674 [ 82.266073] LR is at composite_setup+0xf20/0x1674 [ 82.270760] pc : [<c03510d4>] lr : [<c03511b8>] psr: 600001d3 [ 82.270760] sp : c07c9df0 ip : c0806448 fp : ed8c9c9c [ 82.282216] r10: 00000001 r9 : 00000000 r8 : edaae918 [ 82.287425] r7 : ed551cc0 r6 : 00007fff r5 : 00000000 r4 : ed799634 [ 82.293934] r3 : 00000003 r2 : 00010002 r1 : edaae918 r0 : 0000002e [ 82.300446] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 82.307910] Control: 10c5387d Table: 6bc1804a DAC: 00000015 [ 82.313638] Process swapper/0 (pid: 0, stack limit = 0xc07c8210) [ 82.319627] Stack: (0xc07c9df0 to 0xc07ca000) [ 82.323969] 9de0: 00000000 c06e65f4 00000000 c07c9f68 [ 82.332130] 9e00: 00000067 c07c59ac 000003f7 edaae918 ed8c9c98 ed799690 eca2f140 200001d3 [ 82.340289] 9e20: ee79a2d8 c07c9e88 c07c5304 ffff55db 00010002 edaae810 edaae860 eda96d50 [ 82.348448] 9e40: 00000009 ee264510 00000007 c07ca444 edaae860 c0340890 c0827a40 ffff55e0 [ 82.356607] 9e60: c0827a40 eda96e40 ee264510 edaae810 00000000 edaae860 00000007 c07ca444 [ 82.364766] 9e80: edaae860 c0354170 c03407dc c033db4c edaae810 00000000 00000000 00000010 [ 82.372925] 9ea0: 00000032 c0341670 00000000 00000000 00000001 eda96e00 00000000 00000000 [ 82.381084] 9ec0: 00000000 00000032 c0803a23 ee1aa840 00000001 c005d54c 249e2450 00000000 [ 82.389244] 9ee0: 200001d3 ee1aa840 ee1aa8a0 ed84f4c0 00000000 c07c9f68 00000067 c07c59ac [ 82.397403] 9f00: 00000000 c005d688 ee1aa840 ee1aa8a0 c07db4b4 c006009c 00000032 00000000 [ 82.405562] 9f20: 00000001 c005ce20 c07c59ac c005cf34 f002000c c07ca780 c07c9f68 00000057 [ 82.413722] 9f40: f0020000 413fc090 00000001 c00086b4 c000f804 60000053 ffffffff c07c9f9c [ 82.421880] 9f60: c0803a20 c0011fc0 00000000 00000000 c07c9fb8 c001bee0 c07ca4f0 c057004c [ 82.430040] 9f80: c07ca4fc c0803a20 c0803a20 413fc090 00000001 00000000 01000000 c07c9fb0 [ 82.438199] 9fa0: c000f800 c000f804 60000053 ffffffff 00000000 c0050e70 c0803bc0 c0783bd8 [ 82.446358] 9fc0: ffffffff ffffffff c0783664 00000000 00000000 c07b13e8 00000000 c0803e54 [ 82.454517] 9fe0: c07ca480 c07b13e4 c07ce40c 4000406a 00000000 40008074 00000000 00000000 [ 82.462689] [<c03510d4>] (composite_setup) from [<c0340890>] (s3c_hsotg_complete_setup+0xb4/0x418) [ 82.471626] [<c0340890>] (s3c_hsotg_complete_setup) from [<c0354170>] (usb_gadget_giveback_request+0xc/0x10) [ 82.481429] [<c0354170>] (usb_gadget_giveback_request) from [<c033db4c>] (s3c_hsotg_complete_request+0xcc/0x12c) [ 82.491583] [<c033db4c>] (s3c_hsotg_complete_request) from [<c0341670>] (s3c_hsotg_irq+0x4fc/0x558) [ 82.500614] [<c0341670>] (s3c_hsotg_irq) from [<c005d54c>] (handle_irq_event_percpu+0x50/0x150) [ 82.509291] [<c005d54c>] (handle_irq_event_percpu) from [<c005d688>] (handle_irq_event+0x3c/0x5c) [ 82.518145] [<c005d688>] (handle_irq_event) from [<c006009c>] (handle_fasteoi_irq+0xd4/0x18c) [ 82.526650] [<c006009c>] (handle_fasteoi_irq) from [<c005ce20>] (generic_handle_irq+0x20/0x30) [ 82.535242] [<c005ce20>] (generic_handle_irq) from [<c005cf34>] (__handle_domain_irq+0x6c/0xdc) [ 82.543923] [<c005cf34>] (__handle_domain_irq) from [<c00086b4>] (gic_handle_irq+0x2c/0x6c) [ 82.552256] [<c00086b4>] (gic_handle_irq) from [<c0011fc0>] (__irq_svc+0x40/0x74) [ 82.559716] Exception stack(0xc07c9f68 to 0xc07c9fb0) [ 82.564753] 9f60: 00000000 00000000 c07c9fb8 c001bee0 c07ca4f0 c057004c [ 82.572913] 9f80: c07ca4fc c0803a20 c0803a20 413fc090 00000001 00000000 01000000 c07c9fb0 [ 82.581069] 9fa0: c000f800 c000f804 60000053 ffffffff [ 82.586113] [<c0011fc0>] (__irq_svc) from [<c000f804>] (arch_cpu_idle+0x30/0x3c) [ 82.593491] [<c000f804>] (arch_cpu_idle) from [<c0050e70>] (cpu_startup_entry+0x128/0x1a4) [ 82.601740] [<c0050e70>] (cpu_startup_entry) from [<c0783bd8>] (start_kernel+0x350/0x3bc) [ 82.609890] Code: 0a000002 e3530005 05975010 15975008 (e5953000) [ 82.615965] ---[ end trace f57d5f599a5f1bfa ]--- Most of kernel code assume that interface array in struct usb_configuration is NULL terminated. When gadget is composed with configfs configuration structure may be reused for different functions set. This bug happens because purge_configs_funcs() sets only next_interface_id to 0. Interface array still contains pointers to already freed interfaces. If in second try we add less interfaces than earlier we may access unallocated memory when trying to get interface descriptors. Signed-off-by:
Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Alban Bedel authored
commit 8e71c04f upstream. In SPI mode the transfer buffer is locked with a mutex. However this mutex is only initilized after the probe, but some transfer needs to be done in the probe. To fix this bug we move the mutex initialization at the beginning of the device probe. Signed-off-by:
Alban Bedel <alban.bedel@avionic-design.de> Acked-by:
Denis Ciocca <denis.ciocca@st.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> [ luis: backported to 3.16: - use 'pdata' instead of 'press_data' in st_press_common_probe() - adjusted context ] Signed-off-by:
-
Gabriele Mazzotta authored
commit 09c5b480 upstream. When the LPM policy is set to ATA_LPM_MAX_POWER, the device might generate a spurious PHY event that cuases errors on the link. Ignore this event if it occured within 10s after the policy change. The timeout was chosen observing that on a Dell XPS13 9333 these spurious events can occur up to roughly 6s after the policy change. Link: http://lkml.kernel.org/g/3352987.ugV1Ipy7Z5@xps13Signed-off-by:
Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by:
-
Gabriele Mazzotta authored
commit 8393b811 upstream. This is a preparation commit that will allow to add other criteria according to which PHY events should be dropped. Signed-off-by:
-
Thomas Betker authored
commit 97ffae1d upstream. The VREFN channel is bipolar, not unipolar. Small negative values do occur (e.g., -1mV), and unsigned conversion maps them incorrectly to large positive values (about +1V), so fix this. Signed-off-by:
Thomas Betker <thomas.betker@rohde-schwarz.com> Signed-off-by:
-
Thomas Betker authored
commit 00db4e52 upstream. The scaling factor for VREFP is 3.0/4096, not 1.0/4096; fix this to get correct readings. Signed-off-by:
-
Thomas Betker authored
commit d6c96c42 upstream. For the "vccaux" channel, read the VCCAUX register, not VCCINT. Signed-off-by:
-
Thomas Betker authored
commit 3960d2c0 upstream. Define the register addresses for MIN_VCCPINT, MIN_VCCPAUX, MIN_VCCO_DDR correctly. Signed-off-by:
-
Srinivas Pandruvada authored
commit 964e2255 upstream. Fix "null" in the raw attribute and scan elements. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Srinivas Pandruvada authored
commit c2aab3d5 upstream. Currently in_proximity_(null)_raw is getting presented as raw sysfs attribute. Same with the scan_elements. The modifier doesn't apply to this channel. Signed-off-by:
-
Eugene Shatokhin authored
commit c80e5c0c upstream. On x86-64, __copy_instruction() always returns 0 (error) if the instruction uses %rip-relative addressing. This is because kernel_insn_init() is called the second time for 'insn' instance in such cases and sets all its fields to 0. Because of this, trying to place a kprobe on such instruction will fail, register_kprobe() will return -EINVAL. This patch fixes the problem. Signed-off-by:
Eugene Shatokhin <eugene.shatokhin@rosalab.ru> Signed-off-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Link: http://lkml.kernel.org/r/20150317100918.28349.94654.stgit@localhost.localdomainSigned-off-by:
Ingo Molnar <mingo@kernel.org> [ luis: backported to 3.16: used Eugene's backport for 3.16.y-3.18.y ] Signed-off-by:
-
Luis Henriques authored
Signed-off-by:
-
- 27 May, 2015 1 commit
-
-
Eric Work authored
commit a8115776 upstream. The variable "sector" in "raid0_make_request()" was improperly updated by a call to "sector_div()" which modifies its first argument in place. Commit 47d68979 restored this variable after the call for later re-use. Unfortunetly the restore was done after the referenced variable "bio" was advanced. This lead to the original value and the restored value being different. Here we move this line to the proper place. One observed side effect of this bug was discarding a file though unlinking would cause an unrelated file's contents to be discarded. Signed-off-by:
NeilBrown <neilb@suse.de> Fixes: 47d68979 ("md/raid0: fix bug with chunksize not a power of 2.") URL: https://bugzilla.kernel.org/show_bug.cgi?id=98501 Cc: Philip Müller <philm@manjaro.org> Signed-off-by:
-
- 20 May, 2015 17 commits
-
-
Dave Chinner authored
commit 5885ebda upstream. A new fsync vs power fail test in xfstests indicated that XFS can have unreliable data consistency when doing extending truncates that require block zeroing. The blocks beyond EOF get zeroed in memory, but we never force those changes to disk before we run the transaction that extends the file size and exposes those blocks to userspace. This can result in the blocks not being correctly zeroed after a crash. Because in-memory behaviour is correct, tools like fsx don't pick up any coherency problems - it's not until the filesystem is shutdown or the system crashes after writing the truncate transaction to the journal but before the zeroed data in the page cache is flushed that the issue is exposed. Fix this by also flushing the dirty data in memory region between the old size and new size when we've found blocks that need zeroing in the truncate process. Reported-by:
Liu Bo <bo.li.liu@oracle.com> Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
-
Chuck Lever authored
commit 5ae711a2 upstream. If ib_query_qp() fails or the memory registration mode isn't supported, don't leak the PD. An orphaned IB/core resource will cause IB module removal to hang. Fixes: bd7ed1d1 ("RPC/RDMA: check selected memory registration ...") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Reviewed-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Peter Zijlstra authored
commit 1fe89e1b upstream. Because task_group() uses a cache of autogroup_task_group(), whose output depends on sched_class, switching classes can generate problems. In particular, when started as fair, the cache points to the autogroup, so when switching to RT the tg_rt_schedulable() test fails for every cpu.rt_{runtime,period}_us change because now the autogroup has tasks and no runtime. Furthermore, going back to the previous semantics of varying task_group() with sched_class has the down-side that the sched_debug output varies as well, even though the task really is in the autogroup. Therefore add an autogroup exception to tg_has_rt_tasks() -- such that both (all) task_group() usages in sched/core now have one. And remove all the remnants of the variable task_group() output. Reported-by:
Zefan Li <lizefan@huawei.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <umgwanakikbuti@gmail.com> Cc: Stefan Bader <stefan.bader@canonical.com> Fixes: 8323f26c ("sched: Fix race in task_group()") Link: http://lkml.kernel.org/r/20150209112237.GR5029@twins.programming.kicks-ass.netSigned-off-by:
-
Yann Droneaud authored
commit d6c763af upstream. Since commit 8a0a9bd4 ('random: make get_random_int() more random'), get_random_int() returns a random value for each call, so comment and hack introduced in mmap_rnd() as part of commit 1d18c47c ('arm64: MMU fault handling and page table management') are incorrects. Commit 1d18c47c seems to use the same hack introduced by commit a5adc91a ('powerpc: Ensure random space between stack and mmaps'), latter copied in commit 5a0efea0 ('sparc64: Sharpen address space randomization calculations.'). But both architectures were cleaned up as part of commit fa8cbaaf ('powerpc+sparc64/mm: Remove hack in mmap randomize layout') as hack is no more needed since commit 8a0a9bd4. So the present patch removes the comment and the hack around get_random_int() on AArch64's mmap_rnd(). Cc: David S. Miller <davem@davemloft.net> Cc: Anton Blanchard <anton@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Dan McGee <dpmcgee@gmail.com> Signed-off-by:
Yann Droneaud <ydroneaud@opteya.com> Signed-off-by:
-
Patrick McHardy authored
commit 16c45eda upstream. Fix a race condition and unnecessary locking: * the root rb_node must only be accessed under the lock in nft_rbtree_lookup() * the lock is not needed in lookup functions in netlink context Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Pablo Neira Ayuso authored
commit d6b6cb1d upstream. If there's an existing base chain, we have to allow to change the default policy without indicating the hook information. However, if the chain doesn't exists, we have to enforce the presence of the hook attribute. Signed-off-by:
-
Pablo Neira Ayuso authored
commit 749177cc upstream. ip6tables extensions check for this flag to restrict match/target to a given protocol. Without this flag set, SYNPROXY6 returns an error. Signed-off-by:
-
Patrick McHardy authored
commit 9889840f upstream. Check that the space required for the expressions doesn't exceed the size of the dlen field, which would lead to the iterators crashing. Signed-off-by:
-
Ian Wilson authored
commit 78146572 upstream. nfnl_cthelper_parse_tuple() is called from nfnl_cthelper_new(), nfnl_cthelper_get() and nfnl_cthelper_del(). In each case they pass a pointer to an nf_conntrack_tuple data structure local variable: struct nf_conntrack_tuple tuple; ... ret = nfnl_cthelper_parse_tuple(&tuple, tb[NFCTH_TUPLE]); The problem is that this local variable is not initialized, and nfnl_cthelper_parse_tuple() only initializes two fields: src.l3num and dst.protonum. This leaves all other fields with undefined values based on whatever is on the stack: tuple->src.l3num = ntohs(nla_get_be16(tb[NFCTH_TUPLE_L3PROTONUM])); tuple->dst.protonum = nla_get_u8(tb[NFCTH_TUPLE_L4PROTONUM]); The symptom observed was that when the rpc and tns helpers were added then traffic to port 1536 was being sent to user-space. Signed-off-by:
Ian Wilson <iwilson@brocade.com> Signed-off-by:
-
Pablo Neira Ayuso authored
commit 59900e0a upstream. In general, if a transaction object is added to the list successfully, we can rely on the abort path to undo what we've done. This allows us to simplify the error handling of the rule replacement path in nf_tables_newrule(). This implicitly fixes an unnecessary removal of the old rule, which needs to be left in place if we fail to replace. Signed-off-by:
-
Ilya Dryomov authored
commit 45002267 upstream. Crush temporary buffers are allocated as per replica size configured by the user. When there are more final osds (to be selected as per rule) than the replicas, buffer overlaps and it causes crash. Now, it ensures that at most num-rep osds are selected even if more number of osds are allowed by the rule. Reflects ceph.git commits 6b4d1aa99718e3b367496326c1e64551330fabc0, 234b066ba04976783d15ff2abc3e81b6cc06fb10. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Lv Zheng authored
commit 1d0a0b2f upstream. ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT and ACPI_FORMAT_UINT64() instead of ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT(). This patch also removes above replaced macros as there are no users. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/b6061237Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: George G. Davis <ggdavisiv@gmail.com> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
-
Lv Zheng authored
commit cc2080b0 upstream. ACPICA commit 7f06739db43a85083a70371c14141008f20b2198 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to convert the %p formats. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/7f06739dSigned-off-by:
-
Lv Zheng authored
commit 6d3fd3cc upstream. ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf There are code pieces converting pointers using "(acpi_physical_address) x" or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them. Known issues: 1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field For the conversions around the table fields, it is better to fix it with alignment also fixed. So this patch doesn't modify such code. There should be no functional problem by leaving them unchanged. Link: https://github.com/acpica/acpica/commit/154f6d07Signed-off-by:
-
Lv Zheng authored
commit f254e3c5 upstream. ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643Signed-off-by:
-
Lv Zheng authored
commit 2b876010 upstream. ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451 It is reported that on a physically 64-bit addressed machine, 32-bit kernel can trigger crashes in accessing the memory regions that are beyond the 32-bit boundary. The region field's start address should still be 32-bit compliant, but after a calculation (adding some offsets), it may exceed the 32-bit boundary. This case is rare and buggy, but there are real BIOSes leaked with such issues (see References below). This patch fixes this gap by always defining IO addresses as 64-bit, and allows OSPMs to optimize it for a real 32-bit machine to reduce the size of the internal objects. Internal acpi_physical_address usages in the structures that can be fixed by this change include: 1. struct acpi_object_region: acpi_physical_address address; 2. struct acpi_address_range: acpi_physical_address start_address; acpi_physical_address end_address; 3. struct acpi_mem_space_context; acpi_physical_address address; 4. struct acpi_table_desc acpi_physical_address address; See known issues 1 for other usages. Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer from same problem, so this patch changes it accordingly. For iasl, it will enforce acpi_physical_address as 32-bit to generate 32-bit OSPM compatible tables on 32-bit platforms, we need to define ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h. Known issues: 1. Cleanup of mapped virtual address In struct acpi_mem_space_context, acpi_physical_address is used as a virtual address: acpi_physical_address mapped_physical_address; It is better to introduce acpi_virtual_address or use acpi_size instead. This patch doesn't make such a change. Because this should be done along with a change to acpi_os_map_memory()/acpi_os_unmap_memory(). There should be no functional problem to leave this unchanged except that only this structure is enlarged unexpectedly. Link: https://github.com/acpica/acpica/commit/aacf863c Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501Reported-and-tested-by:
Paul Menzel <paulepanter@users.sourceforge.net> Reported-and-tested-by:
Sial Nije <sialnije@gmail.com> Signed-off-by:
-
Doug Anderson authored
commit c5272a28 upstream. Way back, when the world was a simpler place and there was no war, no evil, and no kernel bugs, there was just a single pinctrl lock. That was how the world was when (57291ce2 pinctrl: core device tree mapping table parsing support) was written. In that case, there were instances where the pinctrl mutex was already held when pinctrl_register_map() was called, hence a "locked" parameter was passed to the function to indicate that the mutex was already locked (so we shouldn't lock it again). A few years ago in (42fed7ba pinctrl: move subsystem mutex to pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex. ...but (oops) we forgot to re-think about the whole "locked" parameter for pinctrl_register_map(). Basically the "locked" parameter appears to still refer to whether the bigger pinctrl_dev mutex is locked, but we're using it to skip locks of our (now separate) pinctrl_maps_mutex. That's kind of a bad thing(TM). Probably nobody noticed because most of the calls to pinctrl_register_map happen at boot time and we've got synchronous device probing. ...and even cases where we're asynchronous don't end up actually hitting the race too often. ...but after banging my head against the wall for a bug that reproduced 1 out of 1000 reboots and lots of looking through kgdb, I finally noticed this. Anyway, we can now safely remove the "locked" parameter and go back to a war-free, evil-free, and kernel-bug-free world. Fixes: 42fed7ba ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
