summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* i2c: designware: Make dw_readl() and dw_writel() staticJarkko Nikula2015-10-152-4/+2Star
| | | | | | | | | dw_readl() and dw_writel() are not used outside of i2c-designware-core and they are not exported so make them static and remove their forward declaration. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: designware: Remove unused functionsJarkko Nikula2015-10-152-15/+0Star
| | | | | | | | | | i2c_dw_is_enabled() became unused by the commit be58eda775c8 ("i2c: designware-pci: Cleanup driver power management") and i2c_dw_enable() by the commit 3a48d1c08fe0 ("i2c: prevent spurious interrupt on Designware controllers"). Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: designware: Disable interrupts before requesting PCI device interruptJarkko Nikula2015-10-151-1/+1
| | | | | | | | | | | | Device must not generate interrupts before registering the interrupt handler so move i2c_dw_disable_int() before requesting it. There are no known issues with this. The code has been here since commit fe20ff5c7e9c ("i2c-designware: Add support for Designware core behind PCI devices."). Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: designware: Remove interrupt clearing from i2c_dw_pci_probe()Jarkko Nikula2015-10-153-9/+1Star
| | | | | | | | | | | | | There is no need to clear interrupts in i2c_dw_pci_probe() since only place where interrupts are unmasked is i2c_dw_xfer_init() and there interrupts are always cleared after commit 2a2d95e9d6d2 ("i2c: designware: always clear interrupts before enabling them"). This allows to cleanup the code and replace i2c_dw_clear_int() in i2c_dw_xfer_init() by direct register read as there are no other callers. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: img-scb: verify support for requested bit rateSifan Naeem2015-10-101-3/+11
| | | | | | | | | | | | | | | | | | The requested bit rate can be outside the range supported by the driver. The maximum bit rate this driver supports at the moment is 400Khz. If the requested bit rate is larger than the maximum supported by the driver, set the bitrate to the maximum supported before bitrate_khz is calculated. Maximum speed supported by the driver can be increased to 1Mhz by adding support for "fast plus mode" in the future. Fixes: commit 27bce457d588 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver") Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com> Acked-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: James Hartley <james.hartley@imgtec.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: img-scb: Clear line and interrupt status before starting a transferSifan Naeem2015-10-101-0/+9
| | | | | | | | | | | | | Clear line status and all generated interrupts from the interrupt status register before starting a transfer, as we may have unserviced interrupts from previous transfers that might be handled in the context of the new transfer. Fixes: commit 27bce457d588 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver") Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com> Acked-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: James Hartley <james.hartley@imgtec.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: img-scb: use line_status instead of i2c->line_statusSifan Naeem2015-10-101-1/+1
| | | | | | | | | | | | i2c->line_status accumulates the line status bits that have been seen with each interrupt. As we're only interested in that bit from the current interrupt, refer to line_status (the argument to img_i2c_auto) instead of i2c->line_status. Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com> Reviewed-by: James Hartley <james.hartley@imgtec.com> Acked-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: img-scb: fix LOW and HIGH period values for the SCL clockSifan Naeem2015-10-101-13/+17
| | | | | | | | | | | | | | | | | | Currently, after determining the minimum value for the High period (TCKH) the remainder of the internal clock pulses is set as the Low period (TCKL). This causes the i2c clock duty cycle to be much less than 50%. Modify the starting position to TCKH and TCKL at 50% of the internal clock, and adjusts the TCKH and TCKL values from there should the minimum value for TCKL not be met. This results in duty cycles closer to 50%. Fixes: commit 27bce457d588 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver") Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com> Acked-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: James Hartley <james.hartley@imgtec.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: img-scb: use DIV_ROUND_UP to round divisor valuesSifan Naeem2015-10-101-6/+2Star
| | | | | | | | | | | | Using % can be slow depending on the architecture. Using DIV_ROUND_UP is nicer and more efficient way to do it. Fixes: commit 27bce457d588 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver") Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com> Acked-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: James Hartley <james.hartley@imgtec.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: img-scb: do dummy writes before fifo accessSifan Naeem2015-10-101-2/+2
| | | | | | | | | | | | Move scb_wr_rd_fence to before reading from fifo and writing to fifo to make sure the the first read/write is done after the required number of cycles. Fixes: commit 27bce457d588 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver") Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com> Acked-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: James Hartley <james.hartley@imgtec.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: img-scb: enable fencing for all versions of the ipSifan Naeem2015-10-101-6/+2Star
| | | | | | | | | | | | | | | | | | | | | | The code to read from the master read fifo, and write to the master write fifo, checks a bit in an SCB register before every byte to ensure that the fifo is not full (write fifo) or empty (read fifo). Due to clock domain crossing inside the SCB block the updated value of this bit is only visible after 2 cycles. The scb_wr_rd_fence() function does 2 dummy writes (to the read-only revision register), and it's called before reading from or writing to the fifos to ensure that subsequent reads of the fifo status bits do not read stale values. As the 2 dummy writes are required in all versions of the ip, the version check is dropped. Fixes: commit 27bce457d588 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver") Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com> Acked-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: James Hartley <james.hartley@imgtec.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rcar: clean up after refactoringWolfram Sang2015-10-091-23/+9Star
| | | | | | | | Update the comments to match current behaviour. Shorten some comments. Update copyrights. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rcar: revoke START request earlyWolfram Sang2015-10-091-16/+7Star
| | | | | | | | | | | | | | If we don't clear START generation as soon as possible, it may cause another message to be generated. To keep the race window as small as possible, we clear it right at the beginning of the interrupt. We don't need checking since we always want to stop START and STOP generation on the next occasion after we started it. This patch improves the situation but sadly does not completely fix it. It is still to be researched if we can do better given this HW design. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rcar: check master irqs before slave irqsWolfram Sang2015-10-091-8/+5Star
| | | | | | | | Due to broken HW design, master IRQs are more timing critical, so give them precedence over slave IRQ. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rcar: don't issue stop when HW does it automaticallyWolfram Sang2015-10-091-2/+2
| | | | | | | | The manual says (55.4.8.6) that HW does automatically send STOP after NACK was received. My measuerments confirm that. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rcar: init new messages in irqWolfram Sang2015-10-091-37/+37
| | | | | | | | | | | | | | | Setting up new messages was done in process context while handling a message was in interrupt context. Because of the HW design, this IP core is sensitive to timing, so the context switches were too expensive. Move this setup to interrupt context as well. In my test setup, this fixed the occasional 'data byte sent twice' issue which a number of people have seen. It also fixes to send REP_START after a read message which was wrongly send as a STOP + START sequence before. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rcar: refactor setup of a msgWolfram Sang2015-10-091-6/+9
| | | | | | | We want to reuse this function later. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rcar: remove spinlockWolfram Sang2015-10-091-19/+4Star
| | | | | | | | | | | We make sure to reinit the HW in the timeout case; then we know that interrupts are always disabled in the sections protected by the spinlock. Thus, we can simply remove it which is a preparation for further refactoring. While here, rename the timeout variable to time_left which is way more readable. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rcar: remove unused IOERROR stateWolfram Sang2015-10-091-6/+0Star
| | | | | Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rcar: rework hw initWolfram Sang2015-10-091-12/+5Star
| | | | | | | | | | We don't need to init HW before every transfer since we know the HW state then. HW init at probe time is enough. While here, add setting the clock register which belongs to init HW. Also, set MDBS bit since not setting it is prohibited according to the manual. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* Linux 4.3-rc4Linus Torvalds2015-10-041-1/+1
|
* Merge branch 'strscpy' of ↵Linus Torvalds2015-10-0425-37/+188
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile Pull strscpy string copy function implementation from Chris Metcalf. Chris sent this during the merge window, but I waffled back and forth on the pull request, which is why it's going in only now. The new "strscpy()" function is definitely easier to use and more secure than either strncpy() or strlcpy(), both of which are horrible nasty interfaces that have serious and irredeemable problems. strncpy() has a useless return value, and doesn't NUL-terminate an overlong result. To make matters worse, it pads a short result with zeroes, which is a performance disaster if you have big buffers. strlcpy(), by contrast, is a mis-designed "fix" for strlcpy(), lacking the insane NUL padding, but having a differently broken return value which returns the original length of the source string. Which means that it will read characters past the count from the source buffer, and you have to trust the source to be properly terminated. It also makes error handling fragile, since the test for overflow is unnecessarily subtle. strscpy() avoids both these problems, guaranteeing the NUL termination (but not excessive padding) if the destination size wasn't zero, and making the overflow condition very obvious by returning -E2BIG. It also doesn't read past the size of the source, and can thus be used for untrusted source data too. So why did I waffle about this for so long? Every time we introduce a new-and-improved interface, people start doing these interminable series of trivial conversion patches. And every time that happens, somebody does some silly mistake, and the conversion patch to the improved interface actually makes things worse. Because the patch is mindnumbing and trivial, nobody has the attention span to look at it carefully, and it's usually done over large swatches of source code which means that not every conversion gets tested. So I'm pulling the strscpy() support because it *is* a better interface. But I will refuse to pull mindless conversion patches. Use this in places where it makes sense, but don't do trivial patches to fix things that aren't actually known to be broken. * 'strscpy' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: tile: use global strscpy() rather than private copy string: provide strscpy() Make asm/word-at-a-time.h available on all architectures
| * tile: use global strscpy() rather than private copyChris Metcalf2015-09-101-29/+4Star
| | | | | | | | | | | | Now that strscpy() is a standard API, remove the local copy. Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
| * string: provide strscpy()Chris Metcalf2015-09-102-0/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The strscpy() API is intended to be used instead of strlcpy(), and instead of most uses of strncpy(). - Unlike strlcpy(), it doesn't read from memory beyond (src + size). - Unlike strlcpy() or strncpy(), the API provides an easy way to check for destination buffer overflow: an -E2BIG error return value. - The provided implementation is robust in the face of the source buffer being asynchronously changed during the copy, unlike the current implementation of strlcpy(). - Unlike strncpy(), the destination buffer will be NUL-terminated if the string in the source buffer is too long. - Also unlike strncpy(), the destination buffer will not be updated beyond the NUL termination, avoiding strncpy's behavior of zeroing the entire tail end of the destination buffer. (A memset() after the strscpy() can be used if this behavior is desired.) - The implementation should be reasonably performant on all platforms since it uses the asm/word-at-a-time.h API rather than simple byte copy. Kernel-to-kernel string copy is not considered to be performance critical in any case. Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
| * Make asm/word-at-a-time.h available on all architecturesChris Metcalf2015-07-0822-8/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added the x86 implementation of word-at-a-time to the generic version, which previously only supported big-endian. Omitted the x86-specific load_unaligned_zeropad(), which in any case is also not present for the existing BE-only implementation of a word-at-a-time, and is only used under CONFIG_DCACHE_WORD_ACCESS. Added as a "generic-y" to the Kbuilds of all architectures that didn't previously have it. Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
* | Merge tag 'md/4.3-fixes' of git://neil.brown.name/mdLinus Torvalds2015-10-047-26/+28
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull md fixes from Neil Brown: "Assorted fixes for md in 4.3-rc. Two tagged for -stable, and one is really a cleanup to match and improve kmemcache interface. * tag 'md/4.3-fixes' of git://neil.brown.name/md: md/bitmap: don't pass -1 to bitmap_storage_alloc. md/raid1: Avoid raid1 resync getting stuck md: drop null test before destroy functions md: clear CHANGE_PENDING in readonly array md/raid0: apply base queue limits *before* disk_stack_limits md/raid5: don't index beyond end of array in need_this_block(). raid5: update analysis state for failed stripe md: wait for pending superblock updates before switching to read-only
| * | md/bitmap: don't pass -1 to bitmap_storage_alloc.NeilBrown2015-10-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Passing -1 to bitmap_storage_alloc() causes page->index to be set to -1, which is quite problematic. So only pass ->cluster_slot if mddev_is_clustered(). Fixes: b97e92574c0b ("Use separate bitmaps for each nodes in the cluster") Cc: stable@vger.kernel.org (v4.1+) Signed-off-by: NeilBrown <neilb@suse.com>
| * | md/raid1: Avoid raid1 resync getting stuckJes Sorensen2015-10-021-3/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | close_sync() needs to set conf->next_resync to a large, but safe value below MaxSector and use it to determine whether or not to set start_next_window in wait_barrier() Solution suggested by Neil Brown. Reported-by: Nate Dailey <nate.dailey@stratus.com> Tested-by: Xiao Ni <xni@redhat.com> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.com>
| * | md: drop null test before destroy functionsJulia Lawall2015-10-024-14/+7Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove unneeded NULL test. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x; @@ -if (x != NULL) \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x); // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: NeilBrown <neilb@suse.com>
| * | md: clear CHANGE_PENDING in readonly arrayShaohua Li2015-10-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If faulty disks of an array are more than allowed degraded number, the array enters error handling. It will be marked as read-only with MD_CHANGE_PENDING/RECOVERY_NEEDED set. But currently recovery doesn't clear CHANGE_PENDING bit for read-only array. If MD_CHANGE_PENDING is set for a raid5 array, all returned IO will be hold on a list till the bit is clear. But recovery nevery clears this bit, the IO is always in pending state and nevery finish. This has bad effects like upper layer can't get an IO error and the array can't be stopped. Fixes: c3cce6cda162 ("md/raid5: ensure device failure recorded before write request returns.") Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: NeilBrown <neilb@suse.com>
| * | md/raid0: apply base queue limits *before* disk_stack_limitsNeilBrown2015-10-021-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling e.g. blk_queue_max_hw_sectors() after calls to disk_stack_limits() discards the settings determined by disk_stack_limits(). So we need to make those calls first. Fixes: 199dc6ed5179 ("md/raid0: update queue parameter in a safer location.") Cc: stable@vger.kernel.org (v2.6.35+ - please apply with 199dc6ed5179). Reported-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.com>
| * | md/raid5: don't index beyond end of array in need_this_block().NeilBrown2015-10-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When need_this_block probably shouldn't be called when there are more than 2 failed devices, we really don't want it to try indexing beyond the end of the failed_num[] of fdev[] arrays. So limit the loops to at most 2 iterations. Reported-by: Shaohua Li <shli@fb.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * | raid5: update analysis state for failed stripeShaohua Li2015-10-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | handle_failed_stripe() makes the stripe fail, eg, all IO will return with a failure, but it doesn't update stripe_head_state. Later handle_stripe() has special handling for raid6 for handle_stripe_fill(). That check before handle_stripe_fill() doesn't skip the failed stripe and we get a kernel crash in need_this_block. This patch clear the analysis state to make sure no functions wrongly called after handle_failed_stripe() Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: NeilBrown <neilb@suse.com>
| * | md: wait for pending superblock updates before switching to read-onlyNeilBrown2015-10-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a superblock update is pending, wait for it to complete before letting md_set_readonly() switch to readonly. Otherwise we might lose important information about a device having failed. For external arrays, waiting for superblock updates can wait on user-space, so in that case, just return an error. Reported-and-tested-by: Shaohua Li <shli@fb.com> Signed-off-by: NeilBrown <neilb@suse.com>
* | | Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds2015-10-0413-144/+82Star
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull MIPS updates from Ralf Baechle: "This week's round of MIPS fixes: - Fix JZ4740 build - Fix fallback to GFP_DMA - FP seccomp in case of ENOSYS - Fix bootmem panic - A number of FP and CPS fixes - Wire up new syscalls - Make sure BPF assembler objects can properly be disassembled - Fix BPF assembler code for MIPS I" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: scall: Always run the seccomp syscall filters MIPS: Octeon: Fix kernel panic on startup from memory corruption MIPS: Fix R2300 FP context switch handling MIPS: Fix octeon FP context switch handling MIPS: BPF: Fix load delay slots. MIPS: BPF: Do all exports of symbols with FEXPORT(). MIPS: Fix the build on jz4740 after removing the custom gpio.h MIPS: CPS: #ifdef on CONFIG_MIPS_MT_SMP rather than CONFIG_MIPS_MT MIPS: CPS: Don't include MT code in non-MT kernels. MIPS: CPS: Stop dangling delay slot from has_mt. MIPS: dma-default: Fix 32-bit fall back to GFP_DMA MIPS: Wire up userfaultfd and membarrier syscalls.
| * | | MIPS: scall: Always run the seccomp syscall filtersMarkos Chandras2015-10-044-73/+42Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MIPS syscall handler code used to return -ENOSYS on invalid syscalls. Whilst this is expected, it caused problems for seccomp filters because the said filters never had the change to run since the code returned -ENOSYS before triggering them. This caused problems on the chromium testsuite for filters looking for invalid syscalls. This has now changed and the seccomp filters are always run even if the syscall is invalid. We return -ENOSYS once we return from the seccomp filters. Moreover, similar codepaths have been merged in the process which simplifies somewhat the overall syscall code. Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11236/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: Octeon: Fix kernel panic on startup from memory corruptionMatt Bennett2015-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During development it was found that a number of builds would panic during the kernel init process, more specifically in 'delayed_fput()'. The panic showed the kernel trying to access a memory address of '0xb7fdc00' while traversing the 'delayed_fput_list' structure. Comparing this memory address to the value of the pointer used on builds that did not panic confirmed that the pointer on crashing builds must have been corrupted at some stage earlier in the init process. By traversing the list earlier and earlier in the code it was found that 'plat_mem_setup()' was responsible for corrupting the list. Specifically the line: memory = cvmx_bootmem_phy_alloc(mem_alloc_size, __pa_symbol(&__init_end), -1, 0x100000, CVMX_BOOTMEM_FLAG_NO_LOCKING); Which would eventually call: cvmx_bootmem_phy_set_size(new_ent_addr, cvmx_bootmem_phy_get_size (ent_addr) - (desired_min_addr - ent_addr)); Where 'new_ent_addr'=0x4800000 (the address of 'delayed_fput_list') and the second argument (size)=0xb7fdc00 (the address causing the kernel panic). The job of this part of 'plat_mem_setup()' is to allocate chunks of memory for the kernel to use. At the start of each chunk of memory the size of the chunk is written, hence the value 0xb7fdc00 is written onto memory at 0x4800000, therefore the kernel panics when it goes back to access 'delayed_fput_list' later on in the initialisation process. On builds that were not crashing it was found that the compiler had placed 'delayed_fput_list' at 0x4800008, meaning it wasn't corrupted (but something else in memory was overwritten). As can be seen in the first function call above the code begins to allocate chunks of memory beginning from the symbol '__init_end'. The MIPS linker script (vmlinux.lds.S) however defines the .bss section to begin after '__init_end'. Therefore memory within the .bss section is allocated to the kernel to use (System.map shows 'delayed_fput_list' and other kernel structures to be in .bss). To stop the kernel panic (and the .bss section being corrupted) memory should begin being allocated from the symbol '_end'. Signed-off-by: Matt Bennett <matt.bennett@alliedtelesis.co.nz> Acked-by: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: aleksey.makarov@auriga.com Patchwork: https://patchwork.linux-mips.org/patch/11251/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: Fix R2300 FP context switch handlingPaul Burton2015-10-021-27/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 1a3d59579b9f ("MIPS: Tidy up FPU context switching") removed FP context saving from the asm-written resume function in favour of reusing existing code to perform the same task. However it only removed the FP context saving code from the r4k_switch.S implementation of resume. Remove it from the r2300_switch.S implementation too in order to prevent attempting to save the FP context twice, which would likely lead to an exception from the second save because the FPU had already been disabled by the first save. This patch has only been build tested, using rbtx49xx_defconfig. Fixes: 1a3d59579b9f ("MIPS: Tidy up FPU context switching") Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-kernel@vger.kernel.org Cc: Manuel Lauss <manuel.lauss@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/11167/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: Fix octeon FP context switch handlingPaul Burton2015-10-021-25/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 1a3d59579b9f ("MIPS: Tidy up FPU context switching") removed FP context saving from the asm-written resume function in favour of reusing existing code to perform the same task. However it only removed the FP context saving code from the r4k_switch.S implementation of resume. Octeon uses its own implementation in octeon_switch.S, so remove FP context saving there too in order to prevent attempting to save context twice. That formerly led to an exception from the second save as follows because the FPU had already been disabled by the first save: do_cpu invoked from kernel context![#1]: CPU: 0 PID: 2 Comm: kthreadd Not tainted 4.3.0-rc2-dirty #2 task: 800000041f84a008 ti: 800000041f864000 task.ti: 800000041f864000 $ 0 : 0000000000000000 0000000010008ce1 0000000000100000 ffffffffbfffffff $ 4 : 800000041f84a008 800000041f84ac08 800000041f84c000 0000000000000004 $ 8 : 0000000000000001 0000000000000000 0000000000000000 0000000000000001 $12 : 0000000010008ce3 0000000000119c60 0000000000000036 800000041f864000 $16 : 800000041f84ac08 800000000792ce80 800000041f84a008 ffffffff81758b00 $20 : 0000000000000000 ffffffff8175ae50 0000000000000000 ffffffff8176c740 $24 : 0000000000000006 ffffffff81170300 $28 : 800000041f864000 800000041f867d90 0000000000000000 ffffffff815f3fa0 Hi : 0000000000fa8257 Lo : ffffffffe15cfc00 epc : ffffffff8112821c resume+0x9c/0x200 ra : ffffffff815f3fa0 __schedule+0x3f0/0x7d8 Status: 10008ce2 KX SX UX KERNEL EXL Cause : 1080002c (ExcCode 0b) PrId : 000d0601 (Cavium Octeon+) Modules linked in: Process kthreadd (pid: 2, threadinfo=800000041f864000, task=800000041f84a008, tls=0000000000000000) Stack : ffffffff81604218 ffffffff815f7e08 800000041f84a008 ffffffff811681b0 800000041f84a008 ffffffff817e9878 0000000000000000 ffffffff81770000 ffffffff81768340 ffffffff81161398 0000000000000001 0000000000000000 0000000000000000 ffffffff815f4424 0000000000000000 ffffffff81161d68 ffffffff81161be8 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ffffffff8111e16c 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ... Call Trace: [<ffffffff8112821c>] resume+0x9c/0x200 [<ffffffff815f3fa0>] __schedule+0x3f0/0x7d8 [<ffffffff815f4424>] schedule+0x34/0x98 [<ffffffff81161d68>] kthreadd+0x180/0x198 [<ffffffff8111e16c>] ret_from_kernel_thread+0x14/0x1c Tested using cavium_octeon_defconfig on an EdgeRouter Lite. Fixes: 1a3d59579b9f ("MIPS: Tidy up FPU context switching") Reported-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Aleksey Makarov <aleksey.makarov@auriga.com> Cc: linux-kernel@vger.kernel.org Cc: Chandrakala Chavva <cchavva@caviumnetworks.com> Cc: David Daney <david.daney@cavium.com> Cc: Leonid Rosenboim <lrosenboim@caviumnetworks.com> Patchwork: https://patchwork.linux-mips.org/patch/11166/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: BPF: Fix load delay slots.Ralf Baechle2015-10-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The entire bpf_jit_asm.S is written in noreorder mode because "we know better" according to a comment. This also prevented the assembler from throwing in the required NOPs for MIPS I processors which have no load-use interlock, thus the load's consumer might end up using the old value of the register from prior to the load. Fixed by putting the assembler in reorder mode for just the affected load instructions. This is not enough for gas to actually try to be clever by looking at the next instruction and inserting a nop only when needed but as the comment said "we know better", so getting gas to unconditionally emit a NOP is just right in this case and prevents adding further ifdefery. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: BPF: Do all exports of symbols with FEXPORT().Ralf Baechle2015-10-011-6/+3Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FEXPORT also marks the symbol as code using .type symbol, @function. Without objdump -d will output only a hexdump for code following the affected symbols. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: Fix the build on jz4740 after removing the custom gpio.hAlban Bedel2015-10-012-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Somehow the wrong version of the patch to remove the use of custom gpio.h on mips has been merged. This patch add the missing fixes for a build error on jz4740 because linux/gpio.h doesn't provide any machine specfics definitions anymore. Signed-off-by: Alban Bedel <albeu@free.fr> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11089/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: CPS: #ifdef on CONFIG_MIPS_MT_SMP rather than CONFIG_MIPS_MTPaul Burton2015-09-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CONFIG_MIPS_MT symbol can be selected by CONFIG_MIPS_VPE_LOADER in addition to CONFIG_MIPS_MT_SMP. We only want MT code in the CPS SMP boot vector if we're using MT for SMP. Thus switch the config symbol we ifdef against to CONFIG_MIPS_MT_SMP. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10867/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: CPS: Don't include MT code in non-MT kernels.Paul Burton2015-09-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MT-specific code in mips_cps_boot_vpes can safely be omitted from kernels which don't support MT, with the default VPE==0 case being used as it would be after the has_mt (Config3.MT) check failed at runtime. Discarding the code entirely will save us a few bytes & allow cleaner handling of MT ASE instructions by later patches. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10866/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: CPS: Stop dangling delay slot from has_mt.Paul Burton2015-09-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The has_mt macro ended with a branch, leaving its callers with a delay slot that would be executed if Config3.MT is not set. However it would not be executed if Config3 (or earlier Config registers) don't exist which makes it somewhat inconsistent at best. Fill the delay slot in the macro & fix the mips_cps_boot_vpes caller appropriately. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10865/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: dma-default: Fix 32-bit fall back to GFP_DMAJames Hogan2015-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32 zone, as is the case for some 32-bit kernels, then massage_gfp_flags() will cause DMA memory allocated for devices with a 32..63-bit coherent_dma_mask to fall back to using __GFP_DMA, even though there may only be 32-bits of physical address available anyway. Correct that case to compare against a mask the size of phys_addr_t instead of always using a 64-bit mask. Signed-off-by: James Hogan <james.hogan@imgtec.com> Fixes: a2e715a86c6d ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.") Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 2.6.36+ Patchwork: https://patchwork.linux-mips.org/patch/9610/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | MIPS: Wire up userfaultfd and membarrier syscalls.Ralf Baechle2015-09-305-6/+20
| | | | | | | | | | | | | | | | Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* | | | Merge branch 'irq-urgent-for-linus' of ↵Linus Torvalds2015-10-043-3/+21
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Thomas Gleixner: "This update contains: - Fix for a long standing race affecting /proc/irq/NNN - One line fix for ARM GICV3-ITS counting the wrong data - Warning silencing in ARM GICV3-ITS. Another GCC trying to be overly clever issue" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v3-its: Count additional LPIs for the aliased devices irqchip/gic-v3-its: Silence warning when its_lpi_alloc_chunks gets inlined genirq: Fix race in register_irq_proc()
| * | | | irqchip/gic-v3-its: Count additional LPIs for the aliased devicesMarc Zyngier2015-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When configuring the interrupt mapping for a new device, we iterate over all the possible aliases to account for their maximum MSI allocation. This was introduced by e8137f4f5088 ("irqchip: gicv3-its: Iterate over PCI aliases to generate ITS configuration"). Turns out that the code doing that is a bit braindead, and repeatedly accounts for the same device over and over. Fix this by counting the actual alias that is passed to us by the core code. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Alex Shi <alex.shi@linaro.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: David Daney <ddaney.cavm@gmail.com> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1443800646-8074-3-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * | | | irqchip/gic-v3-its: Silence warning when its_lpi_alloc_chunks gets inlinedMarc Zyngier2015-10-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | More agressive inlining in recent versions of GCC have uncovered a new set of warnings: drivers/irqchip/irq-gic-v3-its.c: In function its_msi_prepare: drivers/irqchip/irq-gic-v3-its.c:1148:26: warning: lpi_base may be used uninitialized in this function [-Wmaybe-uninitialized] dev->event_map.lpi_base = lpi_base; ^ drivers/irqchip/irq-gic-v3-its.c:1116:6: note: lpi_base was declared here int lpi_base; ^ drivers/irqchip/irq-gic-v3-its.c:1149:25: warning: nr_lpis may be used uninitialized in this function [-Wmaybe-uninitialized] dev->event_map.nr_lpis = nr_lpis; ^ drivers/irqchip/irq-gic-v3-its.c:1117:6: note: nr_lpis was declared here int nr_lpis; ^ The warning is fairly benign (there is no code path that could actually use uninitialized variables), but let's silence it anyway by zeroing the variables on the error path. Reported-by: Alex Shi <alex.shi@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: David Daney <ddaney.cavm@gmail.com> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1443800646-8074-2-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-06 21:21:21 +0200