Re: [PATCH] uio: fix devm_request_irq usage
Hi, On Fri, Dec 20, 2013 at 08:49:13AM -0800, Greg Kroah-Hartman wrote: On Fri, Dec 20, 2013 at 04:19:47PM +0200, Aaro Koskinen wrote: Commit e6789cd3dfb553077606ccafeb05e0043f072481 (uio: Simplify uio error path by using devres functions) converted uio to use devm_request_irq(). This introduced a change in behaviour since the IRQ is associated with the parent device instead of the created UIO device. The IRQ will remain active after uio_unregister_device() is called, and some drivers will crash because of this. The patch fixes this. What drivers crash because of this? Any in-kernel drivers? I saw a crash with Intel DPDK (http://www.dpdk.org/) igb_uio driver. Basically, they do: uio_unregister_device pci_disable_msix -- this will BUG() if there is an active IRQ I cannot test any of the in-tree UIO drivers, but at least some of them seem to release resources the IRQ handler might use after uio_unregister_device(). So if the IRQ fires results would not probably be very good. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: Replace CONFIG_MIPS64 and CONFIG_MIPS32_R2
Hi, On Sun, Feb 09, 2014 at 05:26:59PM +0100, Jonas Gorski wrote: On Sun, Feb 9, 2014 at 2:32 PM, Paul Bolle pebo...@tiscali.nl wrote: Commit 597ce1723e0f (MIPS: Support for 64-bit FP with O32 binaries) introduced references to two undefined Kconfig macros. CONFIG_MIPS32_R2 should clearly be replaced with CONFIG_CPU_MIPS32_R2. And CONFIG_MIPS64 should apparently be replaced with CONFIG_64BIT. While I agree about the CONFIG_MIPS64 = CONFIG_64BIT replacement, I wonder if CONFIG_MIPS32_R2 shouldn't rather be CONFIG_CPU_MIPSR2 (maybe even the existing CONFIG_CPU_MIPS32_R2 are wrong here). FYI, the 64BIT part is already fixed by http://patchwork.linux-mips.org/patch/6506/. I guess these two changes could be separate patches. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: OMAP2+: Remove MACH_NOKIA_N800
Hi, On Sun, Feb 09, 2014 at 04:01:28PM +0100, Paul Bolle wrote: The last caller of machine_is_nokia_n800() was removed in commit 5a87cde490e1 (ARM: OMAP2+: Remove legacy booting support for n8x0). That means that the Kconfig symbol MACH_NOKIA_N800 is now unused. It can safely be removed. Signed-off-by: Paul Bolle pebo...@tiscali.nl Acked-by: Aaro Koskinen aaro.koski...@iki.fi A. --- Untested. arch/arm/mach-omap2/Kconfig | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 653b489..66da3f5 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -268,9 +268,6 @@ config MACH_OMAP_3430SDP default y select OMAP_PACKAGE_CBB -config MACH_NOKIA_N800 - bool - config MACH_NOKIA_N810 bool @@ -281,7 +278,6 @@ config MACH_NOKIA_N8X0 bool Nokia N800/N810 depends on SOC_OMAP2420 default y - select MACH_NOKIA_N800 select MACH_NOKIA_N810 select MACH_NOKIA_N810_WIMAX select OMAP_PACKAGE_ZAC -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 23/28] Remove MACH_OMAP_H4_OTG
On Sun, Feb 09, 2014 at 07:48:01PM +0100, Richard Weinberger wrote: The symbol is an orphan, get rid of it. Signed-off-by: Richard Weinberger rich...@nod.at Acked-by: Aaro Koskinen aaro.koski...@iki.fi A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH CFT] arm: omap1: Migrate debug_ll macros to use 8250.S
Hi, On Thu, Jul 17, 2014 at 11:54:04AM +0100, Daniel Thompson wrote: The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. [...] + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 !ARCH_OMAP730 Did you try this with omap1_defconfig and then running menuconfig to see how it looks like? The patch allows to select only OMAP730 ports, but the kernel should be bootable on all core types... A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160()
Hi, On Tue, Aug 19, 2014 at 09:45:03AM +1000, Julian Calaby wrote: Stupid question: aren't the Ultra 5 and Ultra 10 essentially the same hardware? Basically yes, but often configurations are different (CPU speed, memory capacity, peripherals, PROM versions). A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH CFT v2] arm: omap1: Migrate debug_ll macros to use 8250.S
Hi, On Fri, Jul 18, 2014 at 03:44:02PM +0100, Daniel Thompson wrote: The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Tested-by: Aaro Koskinen aaro.koski...@iki.fi I tested this on OMAP1510. The generic code works, though there will be some more work for the user. Maybe that's acceptable if we want to get rid of the asm file, since the use case is rare. The patch still has couple typos, see comments below. Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Arnd Bergmann arnd.bergm...@linaro.org Cc: linux-o...@vger.kernel.org --- Notes: Changes since v1: * Removed !ARCH_OMAP7XX from the DEBUG_OMAP1UART1/2/3 options (thanks to Aaro Koskinen) arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 6f9664a..762b3ed 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -463,6 +463,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. ^^ This should be except, also repeated below for ports 2-3. + config DEBUG_OMAP1UART2 + bool Kernel low-level debugging via OMAP1 UART2 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool Kernel low-level debugging via OMAP1 UART3 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART3. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [next-20140808] [staging] [lustre] Fix coding style in llite/remote_perm.c
On Sat, Aug 09, 2014 at 08:22:48PM +, Junien Fridrick wrote: Sorry for the noise, this is part of task 10 of the Eudyptula Challenge. Nothing wrong with the patch itself, but maybe in the future you could put such comments after the --- line so that they won't be included in the git commit logs when the patch is applied (and will end up being noise). A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160()
Hi, On Mon, Aug 18, 2014 at 03:30:16PM +0300, Meelis Roos wrote: U1, U2, U5, U10, E220R, E420R later or some other day, whenever I get to them physically. Ultra 5 is bad news with 3.17-rc1: it almost boots up, then aftyer strarting postfix and ntpd, gets RED state exception and contiunes looping with it (before it gor RED state only after prom reboot). My Ultra 5 is fine with 3.17-rc1 (I'm writing this mail from it), also Ultra 10 seems to be OK based on quick test. I'm going to run GCC 4.9.1 bootstrap testsuite on these machines maybe next week. Unfortunately due to summer schedules I'm a bit lost if there are still some special patches I should try (to get rid of $SUBJECT)? If not I'll probably try it with plain 3.17-rc2. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] cpufreq: Loongson1: Add cpufreq driver for Loongson1B (UPDATED)
Hi, On Wed, Oct 15, 2014 at 03:23:32PM +0800, Kelvin Cheung wrote: This patch adds cpufreq driver for Loongson1B which is capable of changing the CPU frequency dynamically. Signed-off-by: Kelvin Cheung keguang.zh...@gmail.com [...] obj-$(CONFIG_LOONGSON2_CPUFREQ) += loongson2_cpufreq.o +obj-$(CONFIG_LOONGSON1_CPUFREQ) += ls1x-cpufreq.o Why it's called ls1x-cpufreq instead of loongson1_cpufreq? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: use the gnu89 standard explicitly
Hi, On Sun, Oct 19, 2014 at 01:05:22PM -0700, Linus Torvalds wrote: On Sun, Oct 19, 2014 at 9:07 AM, Sasha Levin sasha.le...@oracle.com wrote: gcc5 changes the default standard to c11, rather than gnu89, which makes kernel build unhappy. (I guess the default will be gnu11 instead of c11.) Hmm. Just how unhappy does it make it? Maybe we can instead try to make the build happier with some minimal changes? Or is it really painful? Here's one example how it fails: http://marc.info/?l=gccm=141349914632010w=2 It's probably arch-independent as on SPARC I saw a similar failure (I didn't test any others). A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Ethernet gadget on Nokia n900
Hi, On Sun, Oct 19, 2014 at 09:19:37PM +0200, Pavel Machek wrote: I am trying to use nfsroot, so I can't use modules. Why not? (I am attaching full config, in case I missed something important). I'm using the below config with 3.17 and g_ether works OK. (My initramfs modprobes g_ether, runs busybox ifconfig for usb0 and launches sshd.) A. --- CONFIG_LOCALVERSION=-omap3 CONFIG_KERNEL_LZMA=y CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=20 CONFIG_BLK_DEV_INITRD=y # CONFIG_RD_GZIP is not set CONFIG_EXPERT=y CONFIG_KALLSYMS_ALL=y CONFIG_PROFILING=y CONFIG_OPROFILE=m CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y # CONFIG_EFI_PARTITION is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_ARCH_OMAP3=y # CONFIG_SOC_TI81XX is not set # CONFIG_MACH_OMAP3_BEAGLE is not set # CONFIG_MACH_DEVKIT8000 is not set # CONFIG_MACH_OMAP_LDP is not set # CONFIG_MACH_OMAP3530_LV_SOM is not set # CONFIG_MACH_OMAP3_TORPEDO is not set # CONFIG_MACH_OVERO is not set # CONFIG_MACH_OMAP3517EVM is not set # CONFIG_MACH_OMAP3_PANDORA is not set # CONFIG_MACH_TOUCHBOOK is not set # CONFIG_MACH_OMAP_3430SDP is not set # CONFIG_MACH_NOKIA_RX51 is not set # CONFIG_MACH_CM_T35 is not set # CONFIG_MACH_CM_T3517 is not set # CONFIG_MACH_SBC3530 is not set CONFIG_ARM_THUMBEE=y CONFIG_PREEMPT=y # CONFIG_ATAGS is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y CONFIG_CMDLINE=console=ttyO2,115200 console=tty CONFIG_KEXEC=y CONFIG_BINFMT_MISC=y CONFIG_PM_DEBUG=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_INET=y # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set # CONFIG_INET_DIAG is not set # CONFIG_IPV6 is not set # CONFIG_WIRELESS is not set CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_DEVTMPFS=y CONFIG_MTD=y CONFIG_MTD_BLOCK=y CONFIG_MTD_OOPS=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_OMAP2=y CONFIG_MTD_ONENAND=y CONFIG_MTD_ONENAND_VERIFY_WRITE=y CONFIG_MTD_ONENAND_OMAP2=y CONFIG_MTD_UBI=y # CONFIG_BLK_DEV is not set CONFIG_EEPROM_93CX6=y CONFIG_SENSORS_LIS3_I2C=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_INPUT_POLLDEV=y CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_TWL4030=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_TOUCHSCREEN_TSC2005=y CONFIG_INPUT_MISC=y CONFIG_INPUT_TWL4030_PWRBUTTON=y CONFIG_INPUT_UINPUT=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y CONFIG_HW_RANDOM=y CONFIG_I2C_CHARDEV=y CONFIG_SPI=y CONFIG_SPI_OMAP24XX=y CONFIG_PINCTRL_SINGLE=y CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y CONFIG_GPIO_TWL4030=y CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TWL4030=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_OMAP2_DSS=y # CONFIG_OMAP2_DSS_DPI is not set CONFIG_OMAP2_DSS_SDI=y CONFIG_FB_OMAP2=y # CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set CONFIG_DISPLAY_PANEL_SONY_ACX565AKM=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=y CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_VGA16 is not set # CONFIG_LOGO_LINUX_CLUT224 is not set CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_MUSB_HDRC=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_NOP_USB_XCEIV=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DEBUG=y CONFIG_USB_GADGET_DEBUG_FILES=y CONFIG_USB_ETH=m # CONFIG_USB_ETH_RNDIS is not set CONFIG_MMC=y CONFIG_SDIO_UART=y CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL4030=y CONFIG_DMADEVICES=y CONFIG_DMA_OMAP=y CONFIG_TWL4030_USB=y CONFIG_EXT4_FS=y # CONFIG_FILE_LOCKING is not set # CONFIG_DNOTIFY is not set # CONFIG_INOTIFY_USER is not set CONFIG_TMPFS=y # CONFIG_MISC_FILESYSTEMS is not set # CONFIG_NETWORK_FILESYSTEMS is not set CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_PRINTK_TIME=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_FS=y CONFIG_MAGIC_SYSRQ=y # CONFIG_SCHED_DEBUG is not set # CONFIG_DEBUG_BUGVERBOSE is not set # CONFIG_FTRACE is not set # CONFIG_ARM_UNWIND is not set CONFIG_DEBUG_LL=y CONFIG_DEBUG_OMAP3UART3=y CONFIG_EARLY_PRINTK=y CONFIG_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Ethernet gadget on Nokia n900
Hi, On Tue, Oct 21, 2014 at 12:35:18AM +0300, Aaro Koskinen wrote: On Sun, Oct 19, 2014 at 09:19:37PM +0200, Pavel Machek wrote: I am trying to use nfsroot, so I can't use modules. Why not? (I am attaching full config, in case I missed something important). I'm using the below config with 3.17 and g_ether works OK. Also, I'm using DT boot. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] MIPS/loongson2_cpufreq: Fix CPU clock rate setting mismerge
During 3.16 merge window, parts of the commit 8e8acb32960f
(MIPS/loongson2_cpufreq: Fix CPU clock rate setting) seem to have
been deleted probably due to a mismerge, and as a result cpufreq
is broken again on Loongson2 boards in 3.16 and newer kernels.
Fix by repeating the fix.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: sta...@vger.kernel.org # 3.16
---
arch/mips/loongson/lemote-2f/clock.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/mips/loongson/lemote-2f/clock.c
b/arch/mips/loongson/lemote-2f/clock.c
index a217061..462e34d 100644
--- a/arch/mips/loongson/lemote-2f/clock.c
+++ b/arch/mips/loongson/lemote-2f/clock.c
@@ -91,6 +91,7 @@ EXPORT_SYMBOL(clk_put);
int clk_set_rate(struct clk *clk, unsigned long rate)
{
+ unsigned int rate_khz = rate / 1000;
struct cpufreq_frequency_table *pos;
int ret = 0;
int regval;
@@ -107,9 +108,9 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
propagate_rate(clk);
cpufreq_for_each_valid_entry(pos, loongson2_clockmod_table)
- if (rate == pos-frequency)
+ if (rate_khz == pos-frequency)
break;
- if (rate != pos-frequency)
+ if (rate_khz != pos-frequency)
return -ENOTSUPP;
clk-rate = rate;
--
2.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: add support for gcc 5
On Thu, Sep 04, 2014 at 11:37:19AM -0400, Sasha Levin wrote: We're missing include/linux/compiler-gcc5.h which is required now because gcc branched off to v5 in trunk. Just copy the relevant bits out of include/linux/compiler-gcc4.h, no new code is added as of now. This fixes a build error when using gcc 5. With the new GCC version numbering scheme, does this mean there will be a new such file to be added every year? Maybe this could be handled some other way? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: octeon-hcd: removed unwanted return from void functions
On Mon, Sep 08, 2014 at 07:13:15PM +0200, Nitin Kuppelur wrote: This is a patch to the octeon-hcd.c file that fixes checkpatch.pl warning by removing return statement from void functions. Please format line length to = 76 characters in the commit log. Maybe you could fix __cvmx_usb_perform_complete() as well? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: octeon-hcd: removed unwanted return from void functions
Hi, On Mon, Sep 08, 2014 at 12:33:47PM -0700, Greg KH wrote: On Mon, Sep 08, 2014 at 09:59:23PM +0300, Aaro Koskinen wrote: On Mon, Sep 08, 2014 at 07:13:15PM +0200, Nitin Kuppelur wrote: This is a patch to the octeon-hcd.c file that fixes checkpatch.pl warning by removing return statement from void functions. Please format line length to = 76 characters in the commit log. Maybe you could fix __cvmx_usb_perform_complete() as well? What is wrong with it? That should be in a separate patch... There's return; at the end of void function. I thought the patch was about that, however it seems checkpatch.pl does not seem complain about that. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160()
Hi, On Mon, Aug 18, 2014 at 10:38:50AM -0700, David Miller wrote: All patches are in 3,17-rc1 FYI, the warning/bug still triggers with 3.17-rc2 during GCC bootstrap: [94075.963753] [ cut here ] [94076.018105] WARNING: CPU: 0 PID: 17192 at /home/aaro/los/work/shared/linux-v3.17-rc2/mm/mmap.c:2766 exit_mmap+0x128/0x160() [94076.151407] Modules linked in: [94076.187825] CPU: 0 PID: 17192 Comm: rm Not tainted 3.17.0-rc2-ultra-los_3ec1 #1 [94076.275319] Call Trace: [94076.304490] [004c1308] exit_mmap+0x128/0x160 [94076.364915] [0045118c] mmput+0x2c/0xc0 [94076.419062] [00453cb0] do_exit+0x1b0/0x880 [94076.477387] [00454ff8] do_group_exit+0x38/0xc0 [94076.539880] [00455094] SyS_exit_group+0x14/0x20 [94076.603429] [00406074] linux_sparc_syscall32+0x34/0x60 [94076.674225] ---[ end trace b4b3ce0b3bcc0234 ]--- [94076.729446] BUG: Bad rss-counter state mm:ff0016898000 idx:1 val:2 A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: nokia_h4: remove deprecated IRQF_DISABLED
Hi, On Wed, Oct 01, 2014 at 10:33:48PM +0200, Michael Opdenacker wrote: Remove the use of the IRQF_DISABLED flag from drivers/staging/nokia_h4p/nokia_core.c It's a NOOP since 2.6.35 and it will be removed soon. This driver has been deleted from the staging tree already. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] MIPS/loongson2_cpufreq: Fix CPU clock rate setting mismerge
During 3.16 merge window, parts of the commit 8e8acb32960f
(MIPS/loongson2_cpufreq: Fix CPU clock rate setting) seem to have
been deleted probably due to a mismerge, and as a result cpufreq
is broken again on Loongson2 boards in 3.16 and newer kernels.
Fix by repeating the fix.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: sta...@vger.kernel.org # 3.16
---
arch/mips/loongson/lemote-2f/clock.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/mips/loongson/lemote-2f/clock.c
b/arch/mips/loongson/lemote-2f/clock.c
index a217061..462e34d 100644
--- a/arch/mips/loongson/lemote-2f/clock.c
+++ b/arch/mips/loongson/lemote-2f/clock.c
@@ -91,6 +91,7 @@ EXPORT_SYMBOL(clk_put);
int clk_set_rate(struct clk *clk, unsigned long rate)
{
+ unsigned int rate_khz = rate / 1000;
struct cpufreq_frequency_table *pos;
int ret = 0;
int regval;
@@ -107,9 +108,9 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
propagate_rate(clk);
cpufreq_for_each_valid_entry(pos, loongson2_clockmod_table)
- if (rate == pos-frequency)
+ if (rate_khz == pos-frequency)
break;
- if (rate != pos-frequency)
+ if (rate_khz != pos-frequency)
return -ENOTSUPP;
clk-rate = rate;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MIPS/loongson2_cpufreq: Fix CPU clock rate setting mismerge
During 3.16 merge window, parts of the commit 8e8acb32960f
(MIPS/loongson2_cpufreq: Fix CPU clock rate setting) seem to have
been deleted probably due to a mismerge, and as a result cpufreq
is broken again on Loongson2 boards in 3.16 and newer kernels.
Fix by repeating the fix.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: sta...@vger.kernel.org # 3.16
---
arch/mips/loongson/lemote-2f/clock.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/mips/loongson/lemote-2f/clock.c
b/arch/mips/loongson/lemote-2f/clock.c
index a217061..462e34d 100644
--- a/arch/mips/loongson/lemote-2f/clock.c
+++ b/arch/mips/loongson/lemote-2f/clock.c
@@ -91,6 +91,7 @@ EXPORT_SYMBOL(clk_put);
int clk_set_rate(struct clk *clk, unsigned long rate)
{
+ unsigned int rate_khz = rate / 1000;
struct cpufreq_frequency_table *pos;
int ret = 0;
int regval;
@@ -107,9 +108,9 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
propagate_rate(clk);
cpufreq_for_each_valid_entry(pos, loongson2_clockmod_table)
- if (rate == pos-frequency)
+ if (rate_khz == pos-frequency)
break;
- if (rate != pos-frequency)
+ if (rate_khz != pos-frequency)
return -ENOTSUPP;
clk-rate = rate;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/1] powerpc/perf: Adjust callchain based on DWARF debug info
Hi, On Wed, Jun 25, 2014 at 08:49:03AM -0700, Sukadev Bhattiprolu wrote: powerpc/perf: Adjust callchain based on DWARF debug info When saving the callchain on Power, the kernel conservatively saves excess entries in the callchain. A few of these entries are needed in some cases but not others. We should use the DWARF debug information to determine when the entries are needed. This patch breaks perf compilation if DWARF support is not present. DWARF support is auto-detected early in the build, so IMHO either user should be informed to install the needed stuff, or the build should succeed with limited functionality. arch/powerpc/util/skip-callchain-idx.c:13:19: fatal error: dwarf.h: No such file or directory #include dwarf.h ^ compilation terminated. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: omap: fix NACK and Arbitration Lost irq handling
On Tue, Nov 18, 2014 at 09:00:58PM +0400, Alexander Kochetkov wrote:
commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
fired again. As a result, ISR keep processing transfer after it was already
complete (from the driver code point of view).
A didn't see real impacts of the 1d7afc9, but it is really bad idea to
have ISR running on user data after transfer was complete.
It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).
According to specs (if I understood correctly), in case of NACK and AL driver
must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
NACK, AL, ARDY, and XDR (Master Transmitter Mode).
All that is done down the code under the if condition:
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...
The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
no interrupts is fired after ISR informs the rest of driver what transfer
complete.
Note: instead of removing break under NACK case, we could just replace 'break'
with 'continue' and allow NACK transfer to finish using ARDY event. I found
that NACK and ARDY bits usually set together. That case confirm TI wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK
In order if someone interested in the event traces for NACK and AL cases,
I sent them to mailing list.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
Cc: sta...@vger.kernel.org # v3.7+
I could not see any breakage or anything wrong on OMAP2 OMAP3.
On OMAP1 I don't have anything on the OMAP I2C bus, so cannot really
test anything there.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/i2c/busses/i2c-omap.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 90dcc2e..9af7095 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -926,14 +926,12 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- break;
}
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- break;
}
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
Hi, On Tue, Sep 16, 2014 at 11:46:24PM +0100, Daniel Thompson wrote: + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. ^^ + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART2. ^^ + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART3. ^^ I already commented earlier, that expect here is probably a typo? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/15] perf: replace _BSD_SOURCE macro by _DEFAULT_SOURCE
Hi, On Mon, Sep 22, 2014 at 11:53:16PM +0200, Alexis Berlemont wrote: Starting from glibc-2.20, the macro _BSD_SOURCE is deprecated and should be replaced by _DEFAULT_SOURCE. This patch fixes perf build breakage with glibc-2.20, so _DEFAULT_SOURCE is needed. But shouldn't you also keep _BSD_SOURCE still there for a while for backwards compatibility? (Not sure if it has relevance for those using older glibcs...). Anyway to fix the perf + glibc-2.20 build failure: Tested-by: Aaro Koskinen aaro.koski...@iki.fi (BTW, your patch was missing Signed-off-by.) A. --- tools/perf/util/util.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h index 6686436..f56b4e0 100644 --- a/tools/perf/util/util.h +++ b/tools/perf/util/util.h @@ -38,7 +38,7 @@ #define decimal_length(x)((int)(sizeof(x) * 2.56 + 0.5) + 1) #define _ALL_SOURCE 1 -#define _BSD_SOURCE 1 +#define _DEFAULT_SOURCE 1 #define HAS_BOOL #include unistd.h -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: N900 modem support in 3.18-rc1
Hi, On Thu, Nov 13, 2014 at 09:45:36AM -0800, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141113 08:23]: OTOH ofono seems pretty reasonable. So I played a bit, and result is python/pygtk gui which can receive an sms, initiate a call, and report missed call. If someone wants to play, source is at https://gitorious.org/tui/tui/source/b6141107e9341a1412720aed4b0d09143dfa2f4e:ofone Pavel, care to fill in the the following type patch with some instructions in the description now that you got it working? Could we even have some permanent instructions under Documentation/? I did not have luck yet when I tried. I got the /dev/cmt/* entries after adding pm=1 param, but no luck scanning any networks. I haven't tested anything yet, but looking forward to do that during the weekend... Sounds pretty exciting. :-) A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] MIPS: support for hybrid FPRs
Hi, On Thu, Sep 11, 2014 at 08:30:20AM +0100, Paul Burton wrote: Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP MSA. This commit (4227a2d4efc9c84f35826dc4d1e6dc183f6c1c05, bisected) in 3.19-rc1 breaks my Loongson-2F system. I get endless amount of Reserved instruction in kernel code exceptions when booting. See some examples below. Nothing crashes, and there is some forward progress, but obviously it's completely unusable. Any ideas? [2.872000] Reserved instruction in kernel code[#1]: [2.872000] CPU: 0 PID: 231 Comm: hotplug Not tainted 3.18.0-lemote-los_7f08-09423-g988adfd #1 [2.872000] task: 98009f1c7480 ti: 98009a2e8000 task.ti: 98009a2e8000 [2.872000] $ 0 : 77d32c14 0001 [2.872000] $ 4 : 1000802c 98009a2ebeb0 0002 [2.872000] $ 8 : 0010 7efefeff 24242424 81010100 [2.872000] $12 : 100044e1 101f [2.872000] $16 : 00400164 7fdb3ee0 77d62cf8 [2.872000] $20 : 77d61ed0 77d61ed0 004022d8 [2.872000] $24 : 0005 77d4ba80 [2.872000] $28 : 98009a2e8000 98009a2ebe70 7fdb3ee8 802077e0 [2.872000] Hi: 002c [2.872000] Lo: 000b [2.872000] epc : 8020e8d4 do_cpu+0x304/0x4f0 [2.872000] Not tainted [2.872000] ra: 802077e0 ret_from_exception+0x0/0x1c [2.872000] Status: 100044e3 KX SX UX KERNEL EXL IE [2.872000] Cause : 10008028 [2.872000] PrId : 6303 (ICT Loongson-2) [2.872000] Modules linked in: [2.872000] Process hotplug (pid: 231, threadinfo=98009a2e8000, task=98009f1c7480, tls=) [2.872000] Stack : 77d5 77d62c10 c000 77d61ed0 77d622d8 00400164 7fdb3ee0 802077e0 77d32c14 7fdb3da8 77d62bf0 7fdb3db8 7fdb3d90 7fdb3ee8 bba0ffce 7efefeff 24242424 81010100 0fc1 00400164 7fdb3ee0 77d62cf8 77d61ed0 77d61ed0 004022d8 0005 77d4ba80 6474e552 77d6a000 7fdb3d90 7fdb3ee8 77d41038 ... [2.872000] Call Trace: [2.872000] [8020e8d4] do_cpu+0x304/0x4f0 [2.872000] [802077e0] ret_from_exception+0x0/0x1c [2.872000] [2.872000] Code: 30420001 2c420001 0040202d 40038005 2405feff 00651824 40838005 3c032000 3c052400 [2.876000] ---[ end trace 71c7b14ce7da936f ]--- [2.88] Reserved instruction in kernel code[#2]: [2.88] CPU: 0 PID: 232 Comm: hotplug Tainted: G D 3.18.0-lemote-los_7f08-09423-g988adfd #1 [2.88] task: 98009f1c5ea8 ti: 98009a2e4000 task.ti: 98009a2e4000 [2.88] $ 0 : 77832c14 0001 [2.88] $ 4 : 1000802c 98009a2e7eb0 0002 [2.88] $ 8 : 0010 7efefeff 24242424 81010100 [2.88] $12 : 100044e1 101f [2.88] $16 : 00400164 7fd876e0 77862cf8 [2.88] $20 : 77861ed0 77861ed0 004022d8 [2.88] $24 : 0005 7784ba80 [2.88] $28 : 98009a2e4000 98009a2e7e70 7fd876e8 802077e0 [2.88] Hi: 002c [2.88] Lo: 000b [2.88] epc : 8020e8d4 do_cpu+0x304/0x4f0 [2.88] Tainted: G D [2.88] ra: 802077e0 ret_from_exception+0x0/0x1c [2.88] Status: 100044e3 KX SX UX KERNEL EXL IE [2.88] Cause : 10008028 [2.88] PrId : 6303 (ICT Loongson-2) [2.88] Modules linked in: [2.88] Process hotplug (pid: 232, threadinfo=98009a2e4000, task=98009f1c5ea8, tls=) [
Re: [PATCH 07/10] MIPS: support for hybrid FPRs
Hi, On Tue, Dec 23, 2014 at 11:31:54PM +, James Hogan wrote: On Wed, Dec 24, 2014 at 01:21:11AM +0200, Aaro Koskinen wrote: On Thu, Sep 11, 2014 at 08:30:20AM +0100, Paul Burton wrote: Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP MSA. This commit (4227a2d4efc9c84f35826dc4d1e6dc183f6c1c05, bisected) in 3.19-rc1 breaks my Loongson-2F system. I get endless amount of Reserved instruction in kernel code exceptions when booting. See some examples below. Nothing crashes, and there is some forward progress, but obviously it's completely unusable. Any ideas? [2.872000] Reserved instruction in kernel code[#1]: ... Code: 30420001 2c420001 0040202d 40038005 2405feff 00651824 40838005 3c032000 3c052400 0x40038005 = mfc0 v1,$16,5 = mfc0 v1,Config5 Does this help (in linux-next)?: http://git.linux-mips.org/cgit/ralf/upstream-sfr.git/commit/?id=5bba8dec735f18fe7a2fcd8327f28ef095337ff2 Yes, it does. Many thanks! A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v3.19-rc1 regression(?) on N900
Hi, On Thu, Dec 25, 2014 at 10:11:21AM +0100, Pavel Machek wrote: On Thu 2014-12-25 09:32:40, Pali Rohár wrote: On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote: based on automated testing with u-boot as a chained bootloader.. v3.19-rc1: hung https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap 2plus_defconfig/n900.txt Early hang, independend on config. That's dtb too big. Delete something, and it should work again. For me, DT boot works fine with 3.19-rc1 as is... Plus you'll note video regression. ...however, I can confirm that framebuffer is broken: [8.230743] omapfb omapfb: no displays [8.255584] omapfb omapfb: failed to setup omapfb [8.260620] platform omapfb: Driver omapfb requests probe deferral [8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/ocp/spi@48098000/acx565akm@2[0]' - status (0) [8.284271] acx565akm spi1.2: failed to find video source [8.290069] spi spi1.2: Driver acx565akm requests probe deferral I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint by matching reg-id). When I revert that, also FB works with 3.19-rc1. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v3.19-rc1 regression(?) on N900
Hi, On Mon, Dec 29, 2014 at 10:04:46AM +0200, Tomi Valkeinen wrote: On 26/12/14 00:21, Aaro Koskinen wrote: ...however, I can confirm that framebuffer is broken: [8.230743] omapfb omapfb: no displays [8.255584] omapfb omapfb: failed to setup omapfb [8.260620] platform omapfb: Driver omapfb requests probe deferral [8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/ocp/spi@48098000/acx565akm@2[0]' - status (0) [8.284271] acx565akm spi1.2: failed to find video source [8.290069] spi spi1.2: Driver acx565akm requests probe deferral I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint by matching reg-id). When I revert that, also FB works with 3.19-rc1. I've attached a patch for this. Only hack-tested on OMAP3 beagle, so please report if it works. That works, thanks. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S
Hi, On Fri, Oct 24, 2014 at 11:54:32AM +0100, Daniel Thompson wrote: + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. [...] + on OMAP1 based platforms (expect OMAP730) on the UART2. [...] + on OMAP1 based platforms (expect OMAP730) on the UART3. ^^ Spelling again wrong. I think it was already corrected in v11? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty: serial: serial-omap: depend on !8250_omap
Hi, On Mon, Dec 01, 2014 at 02:09:14PM +, One Thousand Gnomes wrote: Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make serial-omap.c transparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of my serial port stopped working questions again. Thata a udev problem not a kernel one surely. People also use serial console to observe the early kernel boot before the userspace is started. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH v8 0/8] TPM 2.0 support
Hi, On Wed, Dec 03, 2014 at 12:21:07AM +0100, Peter Hüwe wrote: --- a/drivers/char/tpm/tpm_i2c_nuvoton.c +++ b/drivers/char/tpm/tpm_i2c_nuvoton.c @@ -605,10 +605,8 @@ static int i2c_nuvoton_probe(struct i2c_client *client, return -ENODEV; rc = tpm_chip_register(chip); - if (rc) - return rc; - return 0; + return rc; Maybe just return tpm_chip_register(chip)? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] MIPS: OCTEON: add crypto helper functions
Add crypto helper functions which are needed for kernel level usage.
The code for these has been extracted from the EdgeRouter Pro GPL tarball.
While at it, also delete duplicate definitions of the functions.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/mips/cavium-octeon/Makefile | 1 +
arch/mips/cavium-octeon/crypto/Makefile| 5 ++
arch/mips/cavium-octeon/crypto/octeon-crypto.c | 66 ++
arch/mips/cavium-octeon/crypto/octeon-crypto.h | 17 +++
arch/mips/include/asm/octeon/octeon.h | 5 --
5 files changed, 89 insertions(+), 5 deletions(-)
create mode 100644 arch/mips/cavium-octeon/crypto/Makefile
create mode 100644 arch/mips/cavium-octeon/crypto/octeon-crypto.c
create mode 100644 arch/mips/cavium-octeon/crypto/octeon-crypto.h
diff --git a/arch/mips/cavium-octeon/Makefile b/arch/mips/cavium-octeon/Makefile
index 42f5f1a..69a8a8d 100644
--- a/arch/mips/cavium-octeon/Makefile
+++ b/arch/mips/cavium-octeon/Makefile
@@ -16,6 +16,7 @@ obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o
csrc-octeon.o
obj-y += dma-octeon.o
obj-y += octeon-memcpy.o
obj-y += executive/
+obj-y += crypto/
obj-$(CONFIG_MTD)+= flash_setup.o
obj-$(CONFIG_SMP)+= smp.o
diff --git a/arch/mips/cavium-octeon/crypto/Makefile
b/arch/mips/cavium-octeon/crypto/Makefile
new file mode 100644
index 000..739b803
--- /dev/null
+++ b/arch/mips/cavium-octeon/crypto/Makefile
@@ -0,0 +1,5 @@
+#
+# OCTEON-specific crypto modules.
+#
+
+obj-y += octeon-crypto.o
diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.c
b/arch/mips/cavium-octeon/crypto/octeon-crypto.c
new file mode 100644
index 000..7c82ff4
--- /dev/null
+++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.c
@@ -0,0 +1,66 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2004-2012 Cavium Networks
+ */
+
+#include asm/cop2.h
+#include linux/module.h
+#include linux/interrupt.h
+
+#include octeon-crypto.h
+
+/**
+ * Enable access to Octeon's COP2 crypto hardware for kernel use. Wrap any
+ * crypto operations in calls to octeon_crypto_enable/disable in order to make
+ * sure the state of COP2 isn't corrupted if userspace is also performing
+ * hardware crypto operations. Allocate the state parameter on the stack.
+ * Preemption must be disabled to prevent context switches.
+ *
+ * @state: Pointer to state structure to store current COP2 state in.
+ *
+ * Returns: Flags to be passed to octeon_crypto_disable()
+ */
+unsigned long octeon_crypto_enable(struct octeon_cop2_state *state)
+{
+ int status;
+ unsigned long flags;
+
+ local_irq_save(flags);
+ status = read_c0_status();
+ write_c0_status(status | ST0_CU2);
+ if (KSTK_STATUS(current) ST0_CU2) {
+ octeon_cop2_save((current-thread.cp2));
+ KSTK_STATUS(current) = ~ST0_CU2;
+ status = ~ST0_CU2;
+ } else if (status ST0_CU2) {
+ octeon_cop2_save(state);
+ }
+ local_irq_restore(flags);
+ return status ST0_CU2;
+}
+EXPORT_SYMBOL_GPL(octeon_crypto_enable);
+
+/**
+ * Disable access to Octeon's COP2 crypto hardware in the kernel. This must be
+ * called after an octeon_crypto_enable() before any context switch or return
to
+ * userspace.
+ *
+ * @state: Pointer to COP2 state to restore
+ * @flags: Return value from octeon_crypto_enable()
+ */
+void octeon_crypto_disable(struct octeon_cop2_state *state,
+ unsigned long crypto_flags)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (crypto_flags ST0_CU2)
+ octeon_cop2_restore(state);
+ else
+ write_c0_status(read_c0_status() ~ST0_CU2);
+ local_irq_restore(flags);
+}
+EXPORT_SYMBOL_GPL(octeon_crypto_disable);
diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
new file mode 100644
index 000..5ca86d4
--- /dev/null
+++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
@@ -0,0 +1,17 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2012-2013 Cavium Inc., All Rights Reserved.
+ */
+#ifndef __LINUX_OCTEON_CRYPTO_H
+#define __LINUX_OCTEON_CRYPTO_H
+
+#include linux/sched.h
+
+extern unsigned long octeon_crypto_enable(struct octeon_cop2_state *state);
+extern void octeon_crypto_disable(struct octeon_cop2_state *state,
+ unsigned long flags);
+
+#endif /* __LINUX_OCTEON_CRYPTO_H */
diff --git a/arch/mips/include/asm/octeon/octeon.h
b/arch/mips/include/asm/octeon/octeon.h
index d781f9e..6dfefd2 100644
--- a/arch/mips/include/asm/octeon/octeon.h
+++ b/arch/mips
[PATCH 0/5] MIPS/crypto: MD5 for OCTEON
Hi, This adds accelerated MD5 cryptoapi module for OCTEON. Tested with 3.19-rc1 on EdgeRouter Lite (OCTEON+) and EdgeRouter Pro (OCTEON2) by running selftest, tcrypt and also by sending TCP MD5SIG traffic between OCTEON - X86 box. Below figures show the improvement on ER Lite compared to md5-generic (calculated from output of tcrypt mode=402). test 0 ( 16 byte blocks, 16 bytes per update, 1 updates): 1.20x faster test 1 ( 64 byte blocks, 16 bytes per update, 4 updates): 1.17x faster test 2 ( 64 byte blocks, 64 bytes per update, 1 updates): 1.30x faster test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 1.14x faster test 4 ( 256 byte blocks, 64 bytes per update, 4 updates): 1.29x faster test 5 ( 256 byte blocks, 256 bytes per update, 1 updates): 1.84x faster test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 1.13x faster test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 2.01x faster test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 2.49x faster test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 1.13x faster test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 2.05x faster test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 2.57x faster test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 2.71x faster test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 1.15x faster test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 2.08x faster test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 2.63x faster test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 2.83x faster test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 1.13x faster test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 2.09x faster test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 2.66x faster test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 2.87x faster test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 2.87x faster A. Aaro Koskinen (5): MIPS: OCTEON: add crypto helper functions MIPS: OCTEON: crypto: add instruction definitions for MD5 MIPS: OCTEON: reintroduce crypto features check MIPS: OCTEON: crypto: add MD5 module crypto: enable OCTEON MD5 module selection arch/mips/cavium-octeon/Makefile | 1 + arch/mips/cavium-octeon/crypto/Makefile | 7 + arch/mips/cavium-octeon/crypto/octeon-crypto.c | 66 +++ arch/mips/cavium-octeon/crypto/octeon-crypto.h | 75 arch/mips/cavium-octeon/crypto/octeon-md5.c | 216 +++ arch/mips/cavium-octeon/executive/octeon-model.c | 6 + arch/mips/include/asm/octeon/octeon-feature.h| 17 +- arch/mips/include/asm/octeon/octeon.h| 5 - crypto/Kconfig | 9 + 9 files changed, 395 insertions(+), 7 deletions(-) create mode 100644 arch/mips/cavium-octeon/crypto/Makefile create mode 100644 arch/mips/cavium-octeon/crypto/octeon-crypto.c create mode 100644 arch/mips/cavium-octeon/crypto/octeon-crypto.h create mode 100644 arch/mips/cavium-octeon/crypto/octeon-md5.c -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] MIPS: OCTEON: reintroduce crypto features check
Reintroduce run-time check for crypto features. The old one was deleted
because it was unreliable, now decide the crypto availability on early
boot when the model string is constructed.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/mips/cavium-octeon/executive/octeon-model.c | 6 ++
arch/mips/include/asm/octeon/octeon-feature.h| 17 +++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/mips/cavium-octeon/executive/octeon-model.c
b/arch/mips/cavium-octeon/executive/octeon-model.c
index e15b049..b2104bd 100644
--- a/arch/mips/cavium-octeon/executive/octeon-model.c
+++ b/arch/mips/cavium-octeon/executive/octeon-model.c
@@ -27,6 +27,9 @@
#include asm/octeon/octeon.h
+enum octeon_feature_bits __octeon_feature_bits __read_mostly;
+EXPORT_SYMBOL_GPL(__octeon_feature_bits);
+
/**
* Read a byte of fuse data
* @byte_addr: address to read
@@ -103,6 +106,9 @@ static const char *__init
octeon_model_get_string_buffer(uint32_t chip_id,
else
suffix = NSP;
+ if (!fus_dat2.s.nocrypto)
+ __octeon_feature_bits |= OCTEON_HAS_CRYPTO;
+
/*
* Assume pass number is encoded using 5:32:0. Exceptions
* will be fixed later.
diff --git a/arch/mips/include/asm/octeon/octeon-feature.h
b/arch/mips/include/asm/octeon/octeon-feature.h
index c4fe81f..8ebd3f57 100644
--- a/arch/mips/include/asm/octeon/octeon-feature.h
+++ b/arch/mips/include/asm/octeon/octeon-feature.h
@@ -46,8 +46,6 @@ enum octeon_feature {
OCTEON_FEATURE_SAAD,
/* Does this Octeon support the ZIP offload engine? */
OCTEON_FEATURE_ZIP,
- /* Does this Octeon support crypto acceleration using COP2? */
- OCTEON_FEATURE_CRYPTO,
OCTEON_FEATURE_DORM_CRYPTO,
/* Does this Octeon support PCI express? */
OCTEON_FEATURE_PCIE,
@@ -86,6 +84,21 @@ enum octeon_feature {
OCTEON_MAX_FEATURE
};
+enum octeon_feature_bits {
+ OCTEON_HAS_CRYPTO = 0x0001, /* Crypto acceleration using COP2 */
+};
+extern enum octeon_feature_bits __octeon_feature_bits;
+
+/**
+ * octeon_has_crypto() - Check if this OCTEON has crypto acceleration support.
+ *
+ * Returns: Non-zero if the feature exists. Zero if the feature does not exist.
+ */
+static inline int octeon_has_crypto(void)
+{
+ return __octeon_feature_bits OCTEON_HAS_CRYPTO;
+}
+
/**
* Determine if the current Octeon supports a specific feature. These
* checks have been optimized to be fairly quick, but they should still
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] MIPS: OCTEON: crypto: add MD5 module
Add OCTEON MD5 module.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/mips/cavium-octeon/crypto/Makefile| 2 +
arch/mips/cavium-octeon/crypto/octeon-crypto.h | 2 +
arch/mips/cavium-octeon/crypto/octeon-md5.c| 216 +
3 files changed, 220 insertions(+)
create mode 100644 arch/mips/cavium-octeon/crypto/octeon-md5.c
diff --git a/arch/mips/cavium-octeon/crypto/Makefile
b/arch/mips/cavium-octeon/crypto/Makefile
index 739b803..a74f76d 100644
--- a/arch/mips/cavium-octeon/crypto/Makefile
+++ b/arch/mips/cavium-octeon/crypto/Makefile
@@ -3,3 +3,5 @@
#
obj-y += octeon-crypto.o
+
+obj-$(CONFIG_CRYPTO_MD5_OCTEON) += octeon-md5.o
diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
index 3f65bc6..e2a4aec 100644
--- a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
+++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
@@ -14,6 +14,8 @@
#include linux/sched.h
#include asm/mipsregs.h
+#define OCTEON_CR_OPCODE_PRIORITY 300
+
extern unsigned long octeon_crypto_enable(struct octeon_cop2_state *state);
extern void octeon_crypto_disable(struct octeon_cop2_state *state,
unsigned long flags);
diff --git a/arch/mips/cavium-octeon/crypto/octeon-md5.c
b/arch/mips/cavium-octeon/crypto/octeon-md5.c
new file mode 100644
index 000..b909881
--- /dev/null
+++ b/arch/mips/cavium-octeon/crypto/octeon-md5.c
@@ -0,0 +1,216 @@
+/*
+ * Cryptographic API.
+ *
+ * MD5 Message Digest Algorithm (RFC1321).
+ *
+ * Adapted for OCTEON by Aaro Koskinen aaro.koski...@iki.fi.
+ *
+ * Based on crypto/md5.c, which is:
+ *
+ * Derived from cryptoapi implementation, originally based on the
+ * public domain implementation written by Colin Plumb in 1993.
+ *
+ * Copyright (c) Cryptoapi developers.
+ * Copyright (c) 2002 James Morris jmor...@intercode.com.au
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include crypto/md5.h
+#include linux/init.h
+#include linux/types.h
+#include linux/module.h
+#include linux/string.h
+#include asm/byteorder.h
+#include linux/cryptohash.h
+#include asm/octeon/octeon.h
+#include crypto/internal/hash.h
+
+#include octeon-crypto.h
+
+/*
+ * We pass everything as 64-bit. OCTEON can handle misaligned data.
+ */
+
+static void octeon_md5_store_hash(struct md5_state *ctx)
+{
+ u64 *hash = (u64 *)ctx-hash;
+
+ write_octeon_64bit_hash_dword(hash[0], 0);
+ write_octeon_64bit_hash_dword(hash[1], 1);
+}
+
+static void octeon_md5_read_hash(struct md5_state *ctx)
+{
+ u64 *hash = (u64 *)ctx-hash;
+
+ hash[0] = read_octeon_64bit_hash_dword(0);
+ hash[1] = read_octeon_64bit_hash_dword(1);
+}
+
+static void octeon_md5_transform(const void *_block)
+{
+ const u64 *block = _block;
+
+ write_octeon_64bit_block_dword(block[0], 0);
+ write_octeon_64bit_block_dword(block[1], 1);
+ write_octeon_64bit_block_dword(block[2], 2);
+ write_octeon_64bit_block_dword(block[3], 3);
+ write_octeon_64bit_block_dword(block[4], 4);
+ write_octeon_64bit_block_dword(block[5], 5);
+ write_octeon_64bit_block_dword(block[6], 6);
+ octeon_md5_start(block[7]);
+}
+
+static int octeon_md5_init(struct shash_desc *desc)
+{
+ struct md5_state *mctx = shash_desc_ctx(desc);
+
+ mctx-hash[0] = cpu_to_le32(0x67452301);
+ mctx-hash[1] = cpu_to_le32(0xefcdab89);
+ mctx-hash[2] = cpu_to_le32(0x98badcfe);
+ mctx-hash[3] = cpu_to_le32(0x10325476);
+ mctx-byte_count = 0;
+
+ return 0;
+}
+
+static int octeon_md5_update(struct shash_desc *desc, const u8 *data,
+unsigned int len)
+{
+ struct md5_state *mctx = shash_desc_ctx(desc);
+ const u32 avail = sizeof(mctx-block) - (mctx-byte_count 0x3f);
+ struct octeon_cop2_state state;
+ unsigned long flags;
+
+ mctx-byte_count += len;
+
+ if (avail len) {
+ memcpy((char *)mctx-block + (sizeof(mctx-block) - avail),
+ data, len);
+ return 0;
+ }
+
+ memcpy((char *)mctx-block + (sizeof(mctx-block) - avail), data,
+ avail);
+
+ local_bh_disable();
+ preempt_disable();
+ flags = octeon_crypto_enable(state);
+ octeon_md5_store_hash(mctx);
+
+ octeon_md5_transform(mctx-block);
+ data += avail;
+ len -= avail;
+
+ while (len = sizeof(mctx-block)) {
+ octeon_md5_transform(data);
+ data += sizeof(mctx-block);
+ len -= sizeof(mctx-block);
+ }
+
+ octeon_md5_read_hash(mctx);
+ octeon_crypto_disable(state, flags);
+ preempt_enable();
+ local_bh_enable();
+
+ memcpy(mctx-block, data
[PATCH 2/5] MIPS: OCTEON: crypto: add instruction definitions for MD5
Add instruction definitions for MD5. Based on information extracted
from EdgeRouter Pro GPL source tarball.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/mips/cavium-octeon/crypto/octeon-crypto.h | 56 ++
1 file changed, 56 insertions(+)
diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
index 5ca86d4..3f65bc6 100644
--- a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
+++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
@@ -4,14 +4,70 @@
* for more details.
*
* Copyright (C) 2012-2013 Cavium Inc., All Rights Reserved.
+ *
+ * MD5 instruction definitions added by Aaro Koskinen aaro.koski...@iki.fi.
+ *
*/
#ifndef __LINUX_OCTEON_CRYPTO_H
#define __LINUX_OCTEON_CRYPTO_H
#include linux/sched.h
+#include asm/mipsregs.h
extern unsigned long octeon_crypto_enable(struct octeon_cop2_state *state);
extern void octeon_crypto_disable(struct octeon_cop2_state *state,
unsigned long flags);
+/*
+ * Macros needed to implement MD5:
+ */
+
+/*
+ * The index can be 0-1.
+ */
+#define write_octeon_64bit_hash_dword(value, index)\
+do { \
+ __asm__ __volatile__ ( \
+ dmtc2 %[rt],0x0048+ STR(index)\
+ : \
+ : [rt] d (value));\
+} while (0)
+
+/*
+ * The index can be 0-1.
+ */
+#define read_octeon_64bit_hash_dword(index)\
+({ \
+ u64 __value;\
+ \
+ __asm__ __volatile__ ( \
+ dmfc2 %[rt],0x0048+ STR(index)\
+ : [rt] =d (__value) \
+ : );\
+ \
+ __value;\
+})
+
+/*
+ * The index can be 0-6.
+ */
+#define write_octeon_64bit_block_dword(value, index) \
+do { \
+ __asm__ __volatile__ ( \
+ dmtc2 %[rt],0x0040+ STR(index)\
+ : \
+ : [rt] d (value));\
+} while (0)
+
+/*
+ * The value is the final block dword (64-bit).
+ */
+#define octeon_md5_start(value)\
+do { \
+ __asm__ __volatile__ ( \
+ dmtc2 %[rt],0x4047\
+ : \
+ : [rt] d (value));\
+} while (0)
+
#endif /* __LINUX_OCTEON_CRYPTO_H */
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] crypto: enable OCTEON MD5 module selection
Enable user to select OCTEON MD5 module. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- crypto/Kconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 87bbc9c..1618468 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -427,6 +427,15 @@ config CRYPTO_MD5 help MD5 message digest algorithm (RFC1321). +config CRYPTO_MD5_OCTEON + tristate MD5 digest algorithm (OCTEON) + depends on CPU_CAVIUM_OCTEON + select CRYPTO_MD5 + select CRYPTO_HASH + help + MD5 message digest algorithm (RFC1321) implemented + using OCTEON crypto instructions, when available. + config CRYPTO_MD5_SPARC64 tristate MD5 digest algorithm (SPARC64) depends on SPARC64 -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/14] MIPS: OCTEON: Add ability to used an initrd from a named memory block.
On Mon, Dec 15, 2014 at 09:03:15PM +0300, Aleksey Makarov wrote: From: David Daney david.da...@cavium.com If 'rd_name=xxx' is passed to the kernel, the named block with name 'xxx' is used for the initrd. Maybe use initrd_name for consistency or even just initrd (if the xxx is not in form of address,size you could assume it to refer to a named block). A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/14] MIPS: OCTEON: Update octeon-model.h code for new SoCs.
Hi, On Mon, Dec 15, 2014 at 09:03:18PM +0300, Aleksey Makarov wrote: From: David Daney david.da...@cavium.com Add coverage for OCTEON III models. [...] +#define OCTEON_IS_OCTEON1() OCTEON_IS_MODEL(OCTEON_CN3XXX) +#define OCTEON_IS_OCTEONPLUS() OCTEON_IS_MODEL(OCTEON_CN5XXX) +#define OCTEON_IS_OCTEON2() \ + (OCTEON_IS_MODEL(OCTEON_CN6XXX) || OCTEON_IS_MODEL(OCTEON_CNF71XX)) + +#define OCTEON_IS_OCTEON3() OCTEON_IS_MODEL(OCTEON_CN7XXX) + +#define OCTEON_IS_OCTEON1PLUS() (OCTEON_IS_OCTEON1() || OCTEON_IS_OCTEONPLUS()) There are no users for these. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/14] MIPS: OCTEON: Add register definitions for OCTEON III reset unit.
Hi, On Mon, Dec 15, 2014 at 09:03:19PM +0300, Aleksey Makarov wrote: From: David Daney david.da...@cavium.com Needed by follow-on patches. Looks like only one of the unions was needed (cvmx_rst_boot)...? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/14] MIPS: OCTEON: Handle OCTEON III in csrc-octeon.
Hi,
On Mon, Dec 15, 2014 at 09:03:20PM +0300, Aleksey Makarov wrote:
if (current_cpu_type() == CPU_CAVIUM_OCTEON2) {
union cvmx_mio_rst_boot rst_boot;
+
rst_boot.u64 = cvmx_read_csr(CVMX_MIO_RST_BOOT);
rdiv = rst_boot.s.c_mul;/* CPU clock */
sdiv = rst_boot.s.pnr_mul; /* I/O clock */
f = (0x8000ull / sdiv) * 2;
+ } else if (current_cpu_type() == CPU_CAVIUM_OCTEON3) {
+ union cvmx_rst_boot rst_boot;
+
+ rst_boot.u64 = cvmx_read_csr(CVMX_RST_BOOT);
+ rdiv = rst_boot.s.c_mul;/* CPU clock */
+ sdiv = rst_boot.s.pnr_mul; /* I/O clock */
+ f = (0x8000ull / sdiv) * 2;
}
The f = ... part could be moved outside the if blocks to avoid copy paste.
A.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/14] MIPS: OCTEON: Handle OCTEON III in csrc-octeon.
Hi,
On Mon, Dec 15, 2014 at 01:29:28PM -0800, David Daney wrote:
On 12/15/2014 01:24 PM, Aaro Koskinen wrote:
On Mon, Dec 15, 2014 at 09:03:20PM +0300, Aleksey Makarov wrote:
if (current_cpu_type() == CPU_CAVIUM_OCTEON2) {
union cvmx_mio_rst_boot rst_boot;
+
rst_boot.u64 = cvmx_read_csr(CVMX_MIO_RST_BOOT);
rdiv = rst_boot.s.c_mul;/* CPU clock */
sdiv = rst_boot.s.pnr_mul; /* I/O clock */
f = (0x8000ull / sdiv) * 2;
+ } else if (current_cpu_type() == CPU_CAVIUM_OCTEON3) {
+ union cvmx_rst_boot rst_boot;
+
+ rst_boot.u64 = cvmx_read_csr(CVMX_RST_BOOT);
+ rdiv = rst_boot.s.c_mul;/* CPU clock */
+ sdiv = rst_boot.s.pnr_mul; /* I/O clock */
+ f = (0x8000ull / sdiv) * 2;
}
The f = ... part could be moved outside the if blocks to avoid copy paste.
No, If you look at the rest of the file, you will find that there are checks
in the form:
if (f != 0) ...
There is a reason that we leave f with its default value of zero in some of
the cases.
Right, sorry, I overlooked the fact that both of those if conditions
can be false.
A.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/14] MIPS: OCTEON: Add register definitions for OCTEON III reset unit.
Hi, On Mon, Dec 15, 2014 at 01:31:28PM -0800, David Daney wrote: On 12/15/2014 01:09 PM, Aaro Koskinen wrote: Hi, On Mon, Dec 15, 2014 at 09:03:19PM +0300, Aleksey Makarov wrote: From: David Daney david.da...@cavium.com Needed by follow-on patches. Looks like only one of the unions was needed (cvmx_rst_boot)...? This follows the form of the other register definition files. If Ralf requests it, we would consider deleting some of the currently unused definitions. Most of this stuff looks like machine generated. Can you at least just make it to minimize the amount of C code it produces? What's the point of having union definitions like e.g. these: + struct cvmx_rst_boot_scn70xx; + struct cvmx_rst_boot_scn70xxp1; + struct cvmx_rst_boot_scn73xx; + struct cvmx_rst_boot_scn78xx; etc? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RCU bug with v3.17-rc3 ?
Hi, On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote: What GCC version are you using? 4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these find_get_entry() crashes with 0x involved smell a lot like the earlier reports from kernels build with those compilers: https://lkml.org/lkml/2014/6/25/456 https://lkml.org/lkml/2014/6/30/375 https://lkml.org/lkml/2014/6/30/660 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 https://lkml.org/lkml/2014/5/9/330 Is it possible to blacklist those GCC versions on ARM somehow as it seems people are still using them? This bug also ruined a file system on one of my boxes last year (see e.g. http://marc.info/?l=linux-arm-kernelm=139033442527244w=2). A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RCU bug with v3.17-rc3 ?
On Fri, Oct 10, 2014 at 05:18:35PM +0100, Russell King - ARM Linux wrote: On Fri, Oct 10, 2014 at 12:47:06AM +0300, Aaro Koskinen wrote: On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote: What GCC version are you using? 4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these find_get_entry() crashes with 0x involved smell a lot like the earlier reports from kernels build with those compilers: https://lkml.org/lkml/2014/6/25/456 https://lkml.org/lkml/2014/6/30/375 https://lkml.org/lkml/2014/6/30/660 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 https://lkml.org/lkml/2014/5/9/330 Is it possible to blacklist those GCC versions on ARM somehow as it seems people are still using them? This bug also ruined a file system on one of my boxes last year (see e.g. http://marc.info/?l=linux-arm-kernelm=139033442527244w=2). Given that, why the fsck (pun intended) did you not shout a little louder about getting it blacklisted. Looking at your marc.info URL, there's very little information there which hints at filesystem corruption, and it's a thread of only *one* message according to marc.info. Even _if_ I did read the message you point to above, that on its own did not hint at filesystem corruption. So, would you please mind passing on further details about this, specifically which function in the ext4 code is affected, so it can be properly written up. I have not done any proper deeper analysis. After I first mailed about the issue I just downgraded GCC and pretty much forgot about it until an engineer from some commercial Linux vendor replied privately months later and kindly pointed me the needed GCC fix (which I then shared in the reply). Then I just moved on using a newer GCC with no issues. Obviously this was not a widespread problem since no one else reported the same. Today I again booted a kernel compiled with GCC 4.8.2 and still was able reproduce the issue, and I think below shows that at least ext3 can easily end up in inconsistent state using these compiler versions: 0) Run the bad kernel: ~ # dmesg|grep GCC [0.00] Linux version 3.17.0-mvebu-los_9755+ (aaro@cooljazz) (gcc version 4.8.2 (GCC) ) #1 Fri Oct 10 21:05:20 EEST 2014 1) Start with small ext3 (writeback) fs with gcc tarball: /mnt/test # ls -l total 84092 -rw-r--r--1 root root 85999682 Apr 24 21:52 gcc-4.8.2.tar.bz2 drwx--2 root root 16384 Oct 10 10:33 lost+found /mnt/test # df -h . FilesystemSize Used Available Use% Mounted on /dev/sdc1 3.8G 90.2M 3.5G 2% /mnt/test 2) Extract, delete crash: /mnt/test # tar xjf gcc-4.8.2.tar.bz2 /mnt/test # rm -rf gcc-4.8.2 rm: can't remove 'gcc-4.8.2/libgfortran/generated': Directory not empty rm: can't remove 'gcc-4.8.2/libgfortran': Directory not empty rm: can't remove 'gcc-4.8.2/gcc/testsuite/gcc.dg/compat/struct-by-value-18a_y.c': No such file or directory rm: can't remove 'gcc-4.8.2/gcc/testsuite/gcc.dg/compat': Directory not empty rm: can't remove 'gcc-4.8.2/gcc/testsuite/gcc.dg/tree-ssa': Directory not empty rm: can't remove 'gcc-4.8.2/gcc/testsuite/gcc.dg': Directory not empty rm: can't remove 'gcc-4.8.2/gcc/testsuite/gfortran.dg/result_default_init_1.f90': No such file or directory rm: can't remove 'gcc-4.8.2/gcc/testsuite/gfortran.dg': Directory not empty [ 960.864433] Unable to handle kernel paging request at virtual address [ 960.930597] pgd = df6e [ 960.990849] [] *pgd=1fffd831, *pte=, *ppte= [ 961.056512] Internal error: Oops: 1 [#1] ARM [ 961.120063] Modules linked in: [ 961.180974] CPU: 0 PID: 684 Comm: rm Not tainted 3.17.0-mvebu-los_9755+ #1 [ 961.247146] task: df447b00 ti: df4de000 task.ti: df4de000 [ 961.311524] PC is at find_get_entry+0x28/0x84 [ 961.375037] LR is at radix_tree_lookup_slot+0x1c/0x2c [ 961.439061] pc : [c006e418]lr : [c018392c]psr: a013 [ 961.439061] sp : df4dfc68 ip : fp : df4dfc7c [ 961.570018] r10: 0001 r9 : c04e3253 r8 : df020b60 [ 961.634596] r7 : 0009001a r6 : r5 : 0009001a r4 : df020c90 [ 961.700070] r3 : r2 : r1 : 0009001a r0 : [ 961.764437] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 961.830518] Control: 0005317f Table: 1f6e DAC: 0015 [ 961.895866] Process rm (pid: 684, stack limit = 0xdf4de1c0) [ 961.960597] Stack: (0xdf4dfc68 to 0xdf4e) [ 962.022968] fc60: 0001 df020c8c df4dfcb4 df4dfc80 c006eef68 c006e400 [ 962.091214] fc80: c00d4e80 c00d4764 1000 0009001a df0200b60 df020b60 [ 962.159490] fca0: df020bd8 df04e4d8 df4dfd04 df4dfcb8 c00d34c0 c006ef44 0 df4dfcc8 [ 962.226940] fcc0: c00d4e80 c00d4764 1000 0001 df4dfd84 dd1c73f0 000900306 [ 962.295558] fce0: 00090068 df020b60 df04e4d8 0181
Re: [GIT PULL] parisc architecture patch for v3.18
Hi, On Mon, Oct 13, 2014 at 10:24:53PM +0200, Helge Deller wrote: On 10/13/2014 03:41 PM, One Thousand Gnomes wrote: I somehow doubt your kill command magically corrects its signal numbering table. Likewise what does gdb do given a core dump that died from one of those signals, and what does your shell report if you kill one that way. It seems to me your minimal set of binaries to swap to get it right is non-zero but not problematic (libc, kill, shells, top, gdb) ? My patch of course just marks the start of a transition phase, in which some few applications need to be rebuilt (libc as the most important one). Busybox handles changed signals correctly after rebuilding against new headers. Based on quick look, GDB has never known about PA-RISC specific numbers, so it has probably always reported some wrong signal name... A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: octeon: Added several blank lines after declarations
Hi,
On Wed, Dec 03, 2014 at 09:43:51PM +, Jamie Lawler wrote:
--- a/drivers/staging/octeon/ethernet-rx.c
+++ b/drivers/staging/octeon/ethernet-rx.c
@@ -84,6 +84,7 @@ static int cvm_irq_cpu;
static void cvm_oct_enable_napi(void *_)
{
int cpu = smp_processor_id();
+
napi_schedule(cvm_oct_napi[cpu].napi);
}
This function has already been deleted from the staging tree.
You need to refresh your patch and see if it's still relevant for
the current tree.
A.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] MIPS: OCTEON: fix kernel crash when offlining a CPU
[ 94.244757] [8115ab04] kthread+0xd4/0xf0
[ 94.249555] [8111c4f0] ret_from_kernel_thread+0x14/0x1c
[ 94.255654]
[ 94.257146]
Code: a2423c40 40026000 30420001 00020336 dc82 10400037
010f 010f
[ 94.267183] ---[ end trace c9e3815ee655bdaa ]---
[ 94.271804] Fatal exception: panic in 5 seconds
Reported-by: Hemmo Nieminen hemmo.niemi...@iki.fi
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: sta...@vger.kernel.org
---
arch/mips/cavium-octeon/smp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
index ecd903d..9673c5b 100644
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
@@ -231,6 +231,7 @@ DEFINE_PER_CPU(int, cpu_state);
static int octeon_cpu_disable(void)
{
unsigned int cpu = smp_processor_id();
+ unsigned long flags;
if (cpu == 0)
return -EBUSY;
@@ -240,9 +241,9 @@ static int octeon_cpu_disable(void)
set_cpu_online(cpu, false);
cpu_clear(cpu, cpu_callin_map);
- local_irq_disable();
+ local_irq_save(flags);
octeon_fixup_irqs();
- local_irq_enable();
+ local_irq_restore(flags);
flush_cache_all();
local_flush_tlb_all();
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MIPS: fix kernel lockup or crash after CPU offline/online
From: Hemmo Nieminen hemmo.niemi...@iki.fi As printk() invocation can cause e.g. a TLB miss, printk() cannot be called before the exception handlers have been properly initialized. This can happen e.g. when netconsole has been loaded as a kernel module and the TLB table has been cleared when a CPU was offline. Call cpu_report() in start_secondary() only after the exception handlers have been initialized to fix this. Without the patch the kernel will randomly either lockup or crash after a CPU is onlined and the console driver is a module. Signed-off-by: Hemmo Nieminen hemmo.niemi...@iki.fi Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: sta...@vger.kernel.org --- arch/mips/kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c index c94c4e9..1c0d8c5 100644 --- a/arch/mips/kernel/smp.c +++ b/arch/mips/kernel/smp.c @@ -123,10 +123,10 @@ asmlinkage void start_secondary(void) unsigned int cpu; cpu_probe(); - cpu_report(); per_cpu_trap_init(false); mips_clockevent_init(); mp_ops-init_secondary(); + cpu_report(); /* * XXX parity protection should be folded in here when it's converted -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MIPS: OCTEON: fix kernel crash when offlining a CPU
Hi, On Thu, Jan 15, 2015 at 11:36:12AM -0800, David Daney wrote: On 01/15/2015 10:49 AM, Aaro Koskinen wrote: octeon_cpu_disable() will unconditionally enable interrupts when called with interrupts disabled. Fix that. interrupts are always disabled here, so... Is that also true for all the currently supported stable kernels...? Or should I just drop Cc: stable from this patch? Just remove this... octeon_fixup_irqs(); -local_irq_enable(); +local_irq_restore(flags); ... and this. flush_cache_all(); local_flush_tlb_all(); You can add an Acked-by me if you do that. Ok, I will do that. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MIPS: OCTEON: fix kernel crash when offlining a CPU
Hi, On Thu, Jan 15, 2015 at 12:10:08PM -0800, David Daney wrote: On 01/15/2015 11:53 AM, Aaro Koskinen wrote: Hi, On Thu, Jan 15, 2015 at 11:36:12AM -0800, David Daney wrote: On 01/15/2015 10:49 AM, Aaro Koskinen wrote: octeon_cpu_disable() will unconditionally enable interrupts when called with interrupts disabled. Fix that. interrupts are always disabled here, so... Is that also true for all the currently supported stable kernels...? I haven't done extensive research recently, but I have removed that pair of local_irq_disable/local_irq_enable in our SDK kernel based on 3.10 Ok, I'll add stable tag only for 3.18 as that is the oldest I can test with at the moment. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] MIPS: OCTEON: fix kernel crash when offlining a CPU
] cpu_stopper_thread+0xd8/0x160 [ 94.238914] [8115ea4c] smpboot_thread_fn+0x1ec/0x1f8 [ 94.244757] [8115ab04] kthread+0xd4/0xf0 [ 94.249555] [8111c4f0] ret_from_kernel_thread+0x14/0x1c [ 94.255654] [ 94.257146] Code: a2423c40 40026000 30420001 00020336 dc82 10400037 010f 010f [ 94.267183] ---[ end trace c9e3815ee655bdaa ]--- [ 94.271804] Fatal exception: panic in 5 seconds Reported-by: Hemmo Nieminen hemmo.niemi...@iki.fi Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: David Daney david.da...@cavium.com Cc: sta...@vger.kernel.org # v3.18+ --- v2: Remove local_irq_disable/local_irq_enable altogether, instead of saving and restoring the old context. v1: http://marc.info/?l=linux-mipsm=142134781818170w=2 arch/mips/cavium-octeon/smp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c index ecd903d..8b1eeff 100644 --- a/arch/mips/cavium-octeon/smp.c +++ b/arch/mips/cavium-octeon/smp.c @@ -240,9 +240,7 @@ static int octeon_cpu_disable(void) set_cpu_online(cpu, false); cpu_clear(cpu, cpu_callin_map); - local_irq_disable(); octeon_fixup_irqs(); - local_irq_enable(); flush_cache_all(); local_flush_tlb_all(); -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] MIPS: fix kernel lockup or crash after CPU offline/online
From: Hemmo Nieminen hemmo.niemi...@iki.fi As printk() invocation can cause e.g. a TLB miss, printk() cannot be called before the exception handlers have been properly initialized. This can happen e.g. when netconsole has been loaded as a kernel module and the TLB table has been cleared when a CPU was offline. Call cpu_report() in start_secondary() only after the exception handlers have been initialized to fix this. Without the patch the kernel will randomly either lockup or crash after a CPU is onlined and the console driver is a module. Signed-off-by: Hemmo Nieminen hemmo.niemi...@iki.fi Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: sta...@vger.kernel.org --- v2: No changes in this patch. v1: http://marc.info/?l=linux-mipsm=142134783418176w=2 arch/mips/kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c index c94c4e9..1c0d8c5 100644 --- a/arch/mips/kernel/smp.c +++ b/arch/mips/kernel/smp.c @@ -123,10 +123,10 @@ asmlinkage void start_secondary(void) unsigned int cpu; cpu_probe(); - cpu_report(); per_cpu_trap_init(false); mips_clockevent_init(); mp_ops-init_secondary(); + cpu_report(); /* * XXX parity protection should be folded in here when it's converted -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SATA: OCTEON: support SATA on OCTEON platform
Hi, On Wed, Jan 21, 2015 at 09:17:31AM -0800, David Daney wrote: On 01/21/2015 08:54 AM, Mark Rutland wrote: While the DTB may already exist, the string cavium,octeon-7130-ahci isn't in mainline, and as far as I can see has never been supported. There seems to be a disconnect here. The DTB comes from the hardware boot environment. The hardware is in some cases already deployed. It is for all practical purposes, impossible to change the DTB. It's possible to change/fix the DTB in platform code like currently done for the OCTEON in-tree DTBs. But that's ugly. I think there should be also a mechanism to override the DTB completely with a user supplied one like with kernel APPENDED_DTB on ARM. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] perf: fix building error in x86_64
Hi, On Fri, Feb 13, 2015 at 03:11:14PM +0800, He Kuang wrote: When build with ARCH=x86_64, perf failed to compile with following error: tests/builtin-test.o:(.data+0x158): undefined reference to `test__perf_time_to_tsc' [...] +ifeq ($(ARCH), x86_64) + override ARCH := x86 +endif The same error happens also with ARCH=i386. So I think both cases should be fixed. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken
On Tue, Jan 27, 2015 at 01:50:22PM -0500, Nicolas Pitre wrote: Hence the ATAG-to-DT compat code in the decompressor. This was meant to smooth things around the transition to DT, etc. After all, those devices with non-replaceable bootloaders where shim layers are not possible should get out of commission eventually? Probably after 5 years there are still people using and hacking mainline Linux with N900 etc., and newer OMAPs (since there no useful devices) are long forgotten... A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: xgifb: XGI_main_26: Change variables that is never used
Hi,
On Wed, Jan 28, 2015 at 10:38:07PM +0100, Rickard Strandqvist wrote:
Variable ar assigned a value that is never used.
Instead use the struct variable of the same name.
This was found using a static code analysis program called cppcheck
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
drivers/staging/xgifb/XGI_main_26.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/xgifb/XGI_main_26.c
b/drivers/staging/xgifb/XGI_main_26.c
index 709d49e..ecfdf34 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -1233,7 +1233,7 @@ static int XGIfb_check_var(struct fb_var_screeninfo
*var, struct fb_info *info)
unsigned int vtotal = 0;
unsigned int drate = 0, hrate = 0;
int found_mode = 0;
- int refresh_rate, search_idx;
+ int search_idx;
if ((var-vmode FB_VMODE_MASK) == FB_VMODE_NONINTERLACED) {
vtotal = var-upper_margin + var-yres + var-lower_margin
@@ -1271,7 +1271,7 @@ static int XGIfb_check_var(struct fb_var_screeninfo
*var, struct fb_info *info)
/* Calculation wrong for 1024x600 - force it to 60Hz */
if ((var-xres == 1024) (var-yres == 600))
- refresh_rate = 60;
+ xgifb_info-refresh_rate = 60;
You are changing behaviour here. Did you test it, is it fixing something?
Otherwise you could just delete the whole if block...
A.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] MIPS: fix kernel lockup or crash after CPU offline/online
Hi,
On Fri, Jan 30, 2015 at 02:59:57PM +, James Hogan wrote:
On 30/01/15 12:47, Maciej W. Rozycki wrote:
On Fri, 30 Jan 2015, James Hogan wrote:
Hmm, why can a call to `printk' cause a TLB miss, what's so special
about
this function? Does it use kernel mapped addresses for any purpose such
as `vmalloc'?
It would be the fact netconsole (or whatever other console is in use) is
built as a kernel module, memory for which is allocated from the vmalloc
area.
Ah, I see, thanks for enlightening me. But in that case wouldn't it be
possible to postpone console output from `printk' until it is safe to
access the device? In a manner similar to how for example we handle calls
to `printk' made from the hardirq context. That would make things less
fragile.
Hmm, kernel/printk/printk.c does have:
static inline int can_use_console(unsigned int cpu)
{
return cpu_online(cpu) || have_callable_console();
}
which should prevent it dumping printk buffer to console. CPU shouldn't
be marked online that early, which suggests that the console has the
CON_ANYTIME flag set, which it probably shouldn't if it depends on
module code. call_console_drivers() seems to ensure the CPU is online or
has CON_ANYTIME before calling the console write callback.
A quick glance and I can't see any evidence of netconsole being able to
get CON_ANYTIME.
It does not set the flag. But flags are kept in module's static data,
so the original problem stays.
A.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: N900 v3.19-rc5 errors
Hi, On Fri, Jan 23, 2015 at 02:15:56PM +0100, Pali Rohár wrote: I'm getting these two errors when booting DT linux v3.19-rc5 in n900 qemu: [0.309234] device-tree: Duplicate name in onenand@0,0, renamed to #1 [0.309417] device-tree: Duplicate name in onenand@0,0, renamed to #2 [0.309844] device-tree: Duplicate name in ethernet@gpmc, renamed to #1 [0.309967] device-tree: Duplicate name in ethernet@gpmc, renamed to #2 [0.730743] [ cut here ] [0.731018] WARNING: CPU: 0 PID: 31 at drivers/memory/omap-gpmc.c:1757 gpmc_probe_generic_child+0x128/0x24c() I don't see these on real HW. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmc does not work in qemu n900
Hi, On Mon, Jan 26, 2015 at 10:04:59PM +0100, Pali Rohár wrote: problem? Why any of these two patches fix problem when mmc is not detected by kernel in qemu (machine n900)? Detection of mmc fails because function mmc_send_op_cond() without one of above patches fails. Has it ever worked? It could be just that QEMU's emulation is broken. Since the kernel works on actual HW, you probably should contact QEMU maintainers. I don't see n900 in Debian's QEMU. There's n800 and n810 but I couldn't boot any of my kernels with those... A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v3.19: Nokia N900 - boot errors
Hi, On Sat, Jan 31, 2015 at 10:28:46AM +0100, Pali Rohár wrote: when I boot 3.19 kernel on real n900 device it show these errors in dmesg: [0.256103] hw-breakpoint: debug architecture 0x4 unsupported. [0.257659] In-band Error seen by MPU at address 0 [0.257720] [ cut here ] [0.257781] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0xd4/0x118() This should be fixed in 3.16-rc6. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v3.19: Nokia N900 - boot errors
Hi, On Sat, Jan 31, 2015 at 12:08:31PM +0100, Pali Rohár wrote: On Saturday 31 January 2015 12:05:09 Aaro Koskinen wrote: Hi, On Sat, Jan 31, 2015 at 10:28:46AM +0100, Pali Rohár wrote: when I boot 3.19 kernel on real n900 device it show these errors in dmesg: [0.256103] hw-breakpoint: debug architecture 0x4 unsupported. [0.257659] In-band Error seen by MPU at address 0 [0.257720] [ cut here ] [0.257781] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0xd4/0x118() This should be fixed in 3.16-rc6. Apparently not, still present in 3.19.0-rc5+. Sorry, I made a typo. I meant 3.19-rc6. The commit is: commit 4b149e417463bbb6d1d9b805f729627ca2b54495 Author: Felipe Balbi ba...@ti.com Date: Tue Jan 6 14:38:08 2015 -0600 irqchip: omap-intc: Fix legacy DMA regression A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting new udev to run with 2.6.28
Hi, On Sat, Jan 10, 2015 at 06:39:20PM +0100, Pavel Machek wrote: N900 has real problems on 3.19, and 2.6.28 should be very well debugged version. Getting it to compile on recent distribution was fun, but I succeeded. Unfortunately, Debian 7's udev does not work with 2.6.28... I guess you will have many other issues too if you want to run such combination (legacy kernel + modern userspace). E.g. current glibc requires = 2.6.32. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting new udev to run with 2.6.28
Hi, On Sat, Jan 10, 2015 at 09:18:05PM +, Al Viro wrote: On Sat, Jan 10, 2015 at 09:13:35PM +0200, Aaro Koskinen wrote: On Sat, Jan 10, 2015 at 06:39:20PM +0100, Pavel Machek wrote: N900 has real problems on 3.19, and 2.6.28 should be very well debugged version. Getting it to compile on recent distribution was fun, but I succeeded. Unfortunately, Debian 7's udev does not work with 2.6.28... I guess you will have many other issues too if you want to run such combination (legacy kernel + modern userspace). E.g. current glibc requires = 2.6.32. How current is current and just what does it require in 2.6.32? In glibc 2.20 the minimum kernel version was increased to 2.6.32. Maybe this patch gives some examples what features they now expect to be present: https://sourceware.org/ml/libc-alpha/2014-04/msg00691.html But looks like Debian 7 is not bleeding-edge and is using older version... A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.19 on Nokia n900: audio quality awful
Hi, On Tue, Jan 06, 2015 at 06:51:15PM +0100, Pavel Machek wrote: On Tue 2015-01-06 11:25:45, Felipe Balbi wrote: On Tue, Jan 06, 2015 at 06:04:33PM +0100, Pavel Machek wrote: In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? $ git bisect start $ git bisect good v3.18 $ git bisect bad that'll help find what caused it. Telling someone to do hard and time consuming job that probably will not succeed, instead of actually providing help. Very very funny. No, that was actually really a good advice. You should try to bisect it. It doesn't take that long (I assume you are cross-compiling instead of doing native builds), also Linux maintainers are generally doing a very good job ensuring the tree is bisectable. I would do it myself, but so far I never have set up my N900 to play any audio and I don't have any reference points between good or bad. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.19 on Nokia n900: audio quality awful
Hi, On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote: PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time. USB networking works fine with 3.19-rc3 and also MMC card rootfs. What issues are you seeing? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.19 on Nokia n900: audio quality awful
On Tue, Jan 06, 2015 at 11:08:05PM +0100, Pavel Machek wrote: On Tue 2015-01-06 22:57:30, Aaro Koskinen wrote: Hi, On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote: PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time. USB networking works fine with 3.19-rc3 and also MMC card rootfs. Does nfsroot work for you? USB networking works as a module but not build-in. [Patch is available for this one.] u-SD card seems to have similar problem. If I try it after boot, I can access it ok, but using u-SD card for rootfs fails. If it works for you, it would be interesting to know. I haven't tried nfsroot, but I've been using USB networking for ssh for a couple of years without issues. I have g_ether as module. Also I recently switched rootfs to u-SD card, and it (MMC) works fine as builtin. But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? I'm loading zImage using 0x directly from the PC. Same here. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hsi: nokia-modem: fix uninitialized device pointer
modem-device was never initialized. This resulted in logs such as:
[ 241.386322] (NULL device *): CMT rst line change detected
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/hsi/clients/nokia-modem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hsi/clients/nokia-modem.c
b/drivers/hsi/clients/nokia-modem.c
index f0c2145..eb4dc63 100644
--- a/drivers/hsi/clients/nokia-modem.c
+++ b/drivers/hsi/clients/nokia-modem.c
@@ -162,6 +162,7 @@ static int nokia_modem_probe(struct device *dev)
return -ENOMEM;
}
dev_set_drvdata(dev, modem);
+ modem-device = dev;
irq = irq_of_parse_and_map(np, 0);
if (!irq) {
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix pyaudio (and probably more)
Hi, On Sun, Jan 04, 2015 at 10:40:49PM +0100, Pavel Machek wrote: On Sun 2015-01-04 21:26:59, Russell King - ARM Linux wrote: On Sun, Jan 04, 2015 at 04:20:57PM -0500, Nicolas Pitre wrote: On Sun, 4 Jan 2015, Linus Torvalds wrote: On Sun, Jan 4, 2015 at 12:56 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: It wasted a lot of people's time before by simply being there and wrong before it was removed. It's only a matter of whose time you want to waste. Really. Really. Shut up. The whole no regressions thing is very much about the fact that we don't waste users time. I was talking about users time all along. Never mind. I'm sorry for the NAK and sorry for attempting to start a discussion to find a better replacement. Nico, I encourage you *not* to back down like this. Linus is right in so far as the regressions issue, but he is *totally* wrong to do the revert, which IMHO has been done out of nothing more than spite. Either *with or without* the revert, the issue still remains, and needs to be addressed properly. With the revert in place, we now have insanely small bogomips values reported via /proc/cpuinfo when hardware timers are used. That needs fixing. Too bad 9fc2105aeaaf56b0cf75296a84702d0f9e64437b's changelog did not mention that :-(. I see reasonable values on Nokia N900. Do I need to change my config to see the problem, or should I try reproducing on socfpga board? I believe Nokia boards fall into the antique hardware category, so for us using such HW the issue is not visible... A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.19 on Nokia n900: audio quality awful
Hi, On Tue, Jan 06, 2015 at 11:58:56PM +0100, Pavel Machek wrote: On Wed 2015-01-07 00:27:17, Aaro Koskinen wrote: On Tue, Jan 06, 2015 at 11:08:05PM +0100, Pavel Machek wrote: On Tue 2015-01-06 22:57:30, Aaro Koskinen wrote: Hi, On Tue, Jan 06, 2015 at 09:50:00PM +0100, Pavel Machek wrote: PS: Unfortunately, N900 will not boot using nfsroot in 3.16+ at least, and boot from MMC card is broken and has been for quite some time. USB networking works fine with 3.19-rc3 and also MMC card rootfs. Does nfsroot work for you? USB networking works as a module but not build-in. [Patch is available for this one.] u-SD card seems to have similar problem. If I try it after boot, I can access it ok, but using u-SD card for rootfs fails. If it works for you, it would be interesting to know. I haven't tried nfsroot, but I've been using USB networking for ssh for a couple of years without issues. I have g_ether as module. Also I recently switched rootfs to u-SD card, and it (MMC) works fine as builtin. But I'm mounting it from userspace (using builtin initramfs inside zImage), with a poll loop that waits for a device to appear. Maybe if you do it from kernel you need to use root wait/delay etc. options? Yes, it works if I mount it later. It fails when done directly using root=, even with rootwait etc. Hard to believe, yes, but try it. You can watch the results on console. Well, I tried and it works. 3.19-rc3 mounting logs are below. I used root=/dev/mmcblk0p2 rootwait. Note that the external MMC is mmcblk0 from kernel point of view. Without serial console I guess you could maybe capture the failure logs using mtdoops (assuming the kernel panics when it fails to mount the rootfs). mtdoops was used even in the sales model kernel, so there is MTD partition reserved already for it called log. I would also recommend using initramfs to do the mounting etc. Then you could use the framebuffer console to observe and debug some obvious issues (assuming the framebuffer works, it often regresses unfortunately...). A. ... [2.145721] Waiting for root device /dev/mmcblk0p2... [2.194335] mmc0: host does not support reading read-only switch, assuming write-enable [2.213775] mmc0: new high speed SDHC card at address [2.227905] mmcblk0: mmc0: SL32G 29.7 GiB [2.252227] mmcblk0: p1 p2 [2.381958] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities [2.399627] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities [2.420196] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem [2.435485] EXT4-fs (mmcblk0p2): write access will be enabled during recovery[2.497375] mmc1: switch to bus width 2 failed [2.510620] mmc1: switch to bus width 1 failed [2.524658] mmc1: new high speed MMC card at address 0001 [2.541229] mmcblk1: mmc1:0001 MMC32G 29.8 GiB [2.553710] mmcblk1boot0: mmc1:0001 MMC32G partition 1 512 KiB [2.569854] mmcblk1boot1: mmc1:0001 MMC32G partition 2 512 KiB [2.587646] mmcblk1: p1 p2 p3 [2.827606] EXT4-fs (mmcblk0p2): recovery complete [2.848327] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) [2.863464] VFS: Mounted root (ext4 filesystem) readonly on device 179:2. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression
On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.
Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().
A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.
Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Signed-off-by: Felipe Balbi ba...@ti.com
I tested this on N950 with 3.19-rc3, and /proc/interrupts looks sane
and also the In-band Error is gone.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
BTW, I guess people still using 3.18.x will get the wrong IRQ for DMA,
so maybe you should consider adding also Cc: stable...
A.
---
drivers/irqchip/irq-omap-intc.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 3c970259c0eb..6ef88f56cf8d 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node
*node)
return ret;
}
-static int __init omap_init_irq_legacy(u32 base)
+static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
{
int j, irq_base;
@@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
irq_base = 0;
}
- domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
+ domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
irq_domain_simple_ops, NULL);
omap_irq_soft_reset();
@@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct
device_node *node)
{
int ret;
- if (node)
+ /*
+ * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
+ * depends is still not ready for linear IRQ domains; because of that
+ * we need to temporarily blacklist OMAP2 and OMAP3 devices from using
+ * linear IRQ Domain until that driver is finally fixed.
+ */
+ if (of_device_is_compatible(node, ti,omap2-intc) ||
+ of_device_is_compatible(node, ti,omap3-intc)) {
+ struct resource res;
+
+ if (of_address_to_resource(node, 0, res))
+ return -ENOMEM;
+
+ base = res.start;
+ ret = omap_init_irq_legacy(base, node);
+ } else if (node) {
ret = omap_init_irq_of(node);
- else
- ret = omap_init_irq_legacy(base);
+ } else {
+ ret = omap_init_irq_legacy(base, NULL);
+ }
if (ret == 0)
omap_irq_enable_protection();
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression
Hi, On Tue, Jan 06, 2015 at 06:05:32PM +, Russell King - ARM Linux wrote: On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote: +* FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c +* depends is still not ready for linear IRQ domains; because of that +* we need to temporarily blacklist OMAP2 and OMAP3 devices from using +* linear IRQ Domain until that driver is finally fixed. finally fixed or finally killed off like it really needs to be, once all users of it are killed. We've been trying to do this for, what, three years now... I finally pushed a WARN_ON() into that code to make it obvious to anyone who uses omap_request_dma() that they really need to update their code. Here's the list of references to that symbol which *still* need to be fixed so that we can kill the legacy DMA driver: drivers/usb/gadget/udc/omap_udc.c: status = omap_request_dma(dma_channel, drivers/usb/gadget/udc/omap_udc.c: status = omap_request_dma(dma_channel, I only learned about this after the WARN_ON() appeared in 3.17 (just couple months ago), and it's on my TODO list... A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH octeon-usb] fix 'line over 80 characters'
Hi, On Wed, Mar 18, 2015 at 08:12:32PM +0530, Amitoj Kaur Chawla wrote: This file contained a warning of a line being over 80 characters and so the file has been edited to remove that warning. Signed-off-by: Amitoj Kaur Chawla amitoj1...@gmail.com --- drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 1daeb31..c8df0c3 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -2884,7 +2884,7 @@ static int __cvmx_usb_poll_channel(struct cvmx_usb_state *usb, int channel) pipe-pid_toggle = 1; if (__cvmx_usb_pipe_needs_split(usb, pipe)) transaction-stage = - CVMX_USB_STAGE_SETUP_SPLIT_COMPLETE; + CVMX_USB_STAGE_SETUP_SPLIT_COMPLETE; This is not an improvement. The proper fix is to refactor the code to avoid deep nesting. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] octeon-usb: fix 'too many leading tabs'
Hi,
On Wed, Mar 18, 2015 at 10:18:29PM +0530, Amitoj Kaur Chawla wrote:
This file contained a lot of warnings of line of over 80 characters
and that the code needs to be refactored due to nested if else
conditions.
The file was accordingly edited to remove some of the warnings.
Signed-off-by: Amitoj Kaur Chawla amitoj1...@gmail.com
---
drivers/staging/octeon-usb/octeon-hcd.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
b/drivers/staging/octeon-usb/octeon-hcd.c
index c8df0c3..e944292 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.c
+++ b/drivers/staging/octeon-usb/octeon-hcd.c
@@ -2920,11 +2920,11 @@ static int __cvmx_usb_poll_channel(struct
cvmx_usb_state *usb, int channel)
*/
if (!usbc_hcchar.s.epdir) {
if (buffer_space_left
pipe-max_packet)
-
transaction-actual_bytes +=
-
buffer_space_left;
+ transaction-actual_bytes +=
+ buffer_space_left;
else
-
transaction-actual_bytes +=
-
pipe-max_packet;
+ transaction-actual_bytes +=
+pipe-max_packet;
You could reduce deep indentation here by moving the whole ACK bit
handling into a separate function.
A.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] gpio: omap: cleanup: get rid of system GPIO - GPIO offset converseations
Hi, On Fri, Mar 20, 2015 at 05:11:23PM +0200, grygorii.stras...@linaro.org wrote: On 03/20/2015 01:00 AM, Tony Lindgren wrote: * grygorii.stras...@linaro.org grygorii.stras...@linaro.org [150319 10:26]: From: Grygorii Strashko grygorii.stras...@linaro.org Now in TI OMAP GPIO driver there are a lot of places where System GPIO number calculated and then converted to GPIO offset. What is worse is that in many place such conversation performed twice or even three times. But actually, we don't need to do that at all, because - gpiolib always passes GPIO offset to GPIO controller - OMAP GPIO driver converted to use IRQ domain, so struct irq_data-hwirq contains GPIO offset Hence, it is safe to convert all GPIO OMAP functions to use GPIO offset instead of system GPIO numbers. Also, this allows to remove unneeded conversations routines #define GPIO_INDEX(bank, gpio) #define GPIO_BIT(bank, gpio) int omap_irq_to_gpio() Right on! This is excellent news. I've tested this set on top of -rc4 plus the patch mentioned below, and I'm not seeing regressions on the platforms I tested with. Wake up to smsc911x ping with off-idle still works on omap3. I only briefly tested on omap1 (osk5912), so I'like to wait for Aaro's ack before this gets merged. I found one build error, other than that, for the whole series please feel free to add: Tested-by: Tony Lindgren t...@atomide.com Thanks Tony. Yep. I'll wait for news from Aaro then will re-send if ok. Works fine on 770 and E3. Tested-by: Aaro Koskinen aaro.koski...@iki.fi A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] MIPS: OCTEON: Use device tree to probe for flash chips.
Hi, On Thu, Mar 05, 2015 at 05:31:31PM +0300, Aleksey Makarov wrote: From: David Daney david.da...@cavium.com Don't assume they are there, the device tree will tell us. Signed-off-by: David Daney david.da...@cavium.com Signed-off-by: Aleksey Makarov aleksey.maka...@auriga.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] mmc: OCTEON: Add host driver for OCTEON MMC controller
Hi, On Thu, Mar 05, 2015 at 05:50:31PM +0300, Aleksey Makarov wrote: The OCTEON MMC controller is currently found on cn61XX and cnf71XX devices. Device parameters are configured from device tree data. eMMC, MMC and SD devices are supported. Signed-off-by: David Daney david.da...@cavium.com Signed-off-by: Leonid Rosenboim lrosenb...@caviumnetworks.com Signed-off-by: Aaron Williams aaron.willi...@cavium.com Signed-off-by: Chandrakala Chavva ccha...@caviumnetworks.com Signed-off-by: Peter Swain psw...@cavium.com [aleksey.maka...@auriga.com: preparation for submission] Signed-off-by: Aleksey Makarov aleksey.maka...@auriga.com Seems to work fine on EdgeRouter Pro (cn61xx). Tested-by: Aaro Koskinen aaro.koski...@iki.fi However, there is a sparse warning that probably needs to be fixed: octeon_mmc.c:1141:29: error: incompatible types for operation (=) octeon_mmc.c:1141:29:left side has type struct gpio_desc *pwr_gpiod octeon_mmc.c:1141:29:right side has type int A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: octeon-usb: Made octeon_usb_match const
Hi, On Mon, Mar 09, 2015 at 11:09:03PM +0100, Mateusz Kulikowski wrote: An of_device_id should be const (checkpatch.pl warning). Signed-off-by: Mateusz Kulikowski mateusz.kulikow...@gmail.com Acked-by: Aaro Koskinen aaro.koski...@iki.fi A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] crypto: OCTEON MD5 bugfix + SHA modules
bytes per update, 256 updates): 1.86x faster test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 6.12x faster test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 9.03x faster test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 10.31x faster test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 1.85x faster test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 6.18x faster test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 9.26x faster test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 10.64x faster test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 10.65x faster A. Aaro Koskinen (7): crypto: octeon - don't disable bottom half in octeon-md5 crypto: octeon - always disable preemption when using crypto engine crypto: octeon - add instruction definitions for SHA1/256/512 crypto: octeon - add SHA1 module crypto: octeon - add SHA256 module crypto: octeon - add SHA512 module crypto: octeon - enable OCTEON SHA1/256/512 module selection arch/mips/cavium-octeon/crypto/Makefile| 5 +- arch/mips/cavium-octeon/crypto/octeon-crypto.c | 4 +- arch/mips/cavium-octeon/crypto/octeon-crypto.h | 83 +++- arch/mips/cavium-octeon/crypto/octeon-md5.c| 8 - arch/mips/cavium-octeon/crypto/octeon-sha1.c | 241 + arch/mips/cavium-octeon/crypto/octeon-sha256.c | 280 + arch/mips/cavium-octeon/crypto/octeon-sha512.c | 277 crypto/Kconfig | 27 +++ 8 files changed, 911 insertions(+), 14 deletions(-) create mode 100644 arch/mips/cavium-octeon/crypto/octeon-sha1.c create mode 100644 arch/mips/cavium-octeon/crypto/octeon-sha256.c create mode 100644 arch/mips/cavium-octeon/crypto/octeon-sha512.c -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] crypto: octeon - add SHA256 module
Add OCTEON SHA256 module.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/mips/cavium-octeon/crypto/Makefile| 1 +
arch/mips/cavium-octeon/crypto/octeon-sha256.c | 280 +
2 files changed, 281 insertions(+)
create mode 100644 arch/mips/cavium-octeon/crypto/octeon-sha256.c
diff --git a/arch/mips/cavium-octeon/crypto/Makefile
b/arch/mips/cavium-octeon/crypto/Makefile
index 3f671d6..47806a5 100644
--- a/arch/mips/cavium-octeon/crypto/Makefile
+++ b/arch/mips/cavium-octeon/crypto/Makefile
@@ -6,3 +6,4 @@ obj-y += octeon-crypto.o
obj-$(CONFIG_CRYPTO_MD5_OCTEON)+= octeon-md5.o
obj-$(CONFIG_CRYPTO_SHA1_OCTEON) += octeon-sha1.o
+obj-$(CONFIG_CRYPTO_SHA256_OCTEON) += octeon-sha256.o
diff --git a/arch/mips/cavium-octeon/crypto/octeon-sha256.c
b/arch/mips/cavium-octeon/crypto/octeon-sha256.c
new file mode 100644
index 000..97e96fe
--- /dev/null
+++ b/arch/mips/cavium-octeon/crypto/octeon-sha256.c
@@ -0,0 +1,280 @@
+/*
+ * Cryptographic API.
+ *
+ * SHA-224 and SHA-256 Secure Hash Algorithm.
+ *
+ * Adapted for OCTEON by Aaro Koskinen aaro.koski...@iki.fi.
+ *
+ * Based on crypto/sha256_generic.c, which is:
+ *
+ * Copyright (c) Jean-Luc Cooke jlco...@certainkey.com
+ * Copyright (c) Andrew McDonald and...@mcdonald.org.uk
+ * Copyright (c) 2002 James Morris jmor...@intercode.com.au
+ * SHA224 Support Copyright 2007 Intel Corporation jonathan.ly...@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include linux/mm.h
+#include crypto/sha.h
+#include linux/init.h
+#include linux/types.h
+#include linux/module.h
+#include asm/byteorder.h
+#include asm/octeon/octeon.h
+#include crypto/internal/hash.h
+
+#include octeon-crypto.h
+
+/*
+ * We pass everything as 64-bit. OCTEON can handle misaligned data.
+ */
+
+static void octeon_sha256_store_hash(struct sha256_state *sctx)
+{
+ u64 *hash = (u64 *)sctx-state;
+
+ write_octeon_64bit_hash_dword(hash[0], 0);
+ write_octeon_64bit_hash_dword(hash[1], 1);
+ write_octeon_64bit_hash_dword(hash[2], 2);
+ write_octeon_64bit_hash_dword(hash[3], 3);
+}
+
+static void octeon_sha256_read_hash(struct sha256_state *sctx)
+{
+ u64 *hash = (u64 *)sctx-state;
+
+ hash[0] = read_octeon_64bit_hash_dword(0);
+ hash[1] = read_octeon_64bit_hash_dword(1);
+ hash[2] = read_octeon_64bit_hash_dword(2);
+ hash[3] = read_octeon_64bit_hash_dword(3);
+}
+
+static void octeon_sha256_transform(const void *_block)
+{
+ const u64 *block = _block;
+
+ write_octeon_64bit_block_dword(block[0], 0);
+ write_octeon_64bit_block_dword(block[1], 1);
+ write_octeon_64bit_block_dword(block[2], 2);
+ write_octeon_64bit_block_dword(block[3], 3);
+ write_octeon_64bit_block_dword(block[4], 4);
+ write_octeon_64bit_block_dword(block[5], 5);
+ write_octeon_64bit_block_dword(block[6], 6);
+ octeon_sha256_start(block[7]);
+}
+
+static int octeon_sha224_init(struct shash_desc *desc)
+{
+ struct sha256_state *sctx = shash_desc_ctx(desc);
+
+ sctx-state[0] = SHA224_H0;
+ sctx-state[1] = SHA224_H1;
+ sctx-state[2] = SHA224_H2;
+ sctx-state[3] = SHA224_H3;
+ sctx-state[4] = SHA224_H4;
+ sctx-state[5] = SHA224_H5;
+ sctx-state[6] = SHA224_H6;
+ sctx-state[7] = SHA224_H7;
+ sctx-count = 0;
+
+ return 0;
+}
+
+static int octeon_sha256_init(struct shash_desc *desc)
+{
+ struct sha256_state *sctx = shash_desc_ctx(desc);
+
+ sctx-state[0] = SHA256_H0;
+ sctx-state[1] = SHA256_H1;
+ sctx-state[2] = SHA256_H2;
+ sctx-state[3] = SHA256_H3;
+ sctx-state[4] = SHA256_H4;
+ sctx-state[5] = SHA256_H5;
+ sctx-state[6] = SHA256_H6;
+ sctx-state[7] = SHA256_H7;
+ sctx-count = 0;
+
+ return 0;
+}
+
+static void __octeon_sha256_update(struct sha256_state *sctx, const u8 *data,
+ unsigned int len)
+{
+ unsigned int partial;
+ unsigned int done;
+ const u8 *src;
+
+ partial = sctx-count % SHA256_BLOCK_SIZE;
+ sctx-count += len;
+ done = 0;
+ src = data;
+
+ if ((partial + len) = SHA256_BLOCK_SIZE) {
+ if (partial) {
+ done = -partial;
+ memcpy(sctx-buf + partial, data,
+ done + SHA256_BLOCK_SIZE);
+ src = sctx-buf;
+ }
+
+ do {
+ octeon_sha256_transform(src);
+ done += SHA256_BLOCK_SIZE;
+ src = data + done;
+ } while (done + SHA256_BLOCK_SIZE = len);
+
+ partial = 0;
+ }
+ memcpy(sctx
[PATCH 7/7] crypto: octeon - enable OCTEON SHA1/256/512 module selection
Enable user to select OCTEON SHA1/256/512 modules. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- crypto/Kconfig | 27 +++ 1 file changed, 27 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 50f4da4..38b2315 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -546,6 +546,15 @@ config CRYPTO_SHA512_SSSE3 Extensions version 1 (AVX1), or Advanced Vector Extensions version 2 (AVX2) instructions, when available. +config CRYPTO_SHA1_OCTEON + tristate SHA1 digest algorithm (OCTEON) + depends on CPU_CAVIUM_OCTEON + select CRYPTO_SHA1 + select CRYPTO_HASH + help + SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented + using OCTEON crypto instructions, when available. + config CRYPTO_SHA1_SPARC64 tristate SHA1 digest algorithm (SPARC64) depends on SPARC64 @@ -610,6 +619,15 @@ config CRYPTO_SHA256 This code also includes SHA-224, a 224 bit hash with 112 bits of security against collision attacks. +config CRYPTO_SHA256_OCTEON + tristate SHA224 and SHA256 digest algorithm (OCTEON) + depends on CPU_CAVIUM_OCTEON + select CRYPTO_SHA256 + select CRYPTO_HASH + help + SHA-256 secure hash standard (DFIPS 180-2) implemented + using OCTEON crypto instructions, when available. + config CRYPTO_SHA256_SPARC64 tristate SHA224 and SHA256 digest algorithm (SPARC64) depends on SPARC64 @@ -631,6 +649,15 @@ config CRYPTO_SHA512 This code also includes SHA-384, a 384 bit hash with 192 bits of security against collision attacks. +config CRYPTO_SHA512_OCTEON + tristate SHA384 and SHA512 digest algorithms (OCTEON) + depends on CPU_CAVIUM_OCTEON + select CRYPTO_SHA512 + select CRYPTO_HASH + help + SHA-512 secure hash standard (DFIPS 180-2) implemented + using OCTEON crypto instructions, when available. + config CRYPTO_SHA512_SPARC64 tristate SHA384 and SHA512 digest algorithm (SPARC64) depends on SPARC64 -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] crypto: octeon - add SHA512 module
Add OCTEON SHA512 module.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/mips/cavium-octeon/crypto/Makefile| 1 +
arch/mips/cavium-octeon/crypto/octeon-sha512.c | 277 +
2 files changed, 278 insertions(+)
create mode 100644 arch/mips/cavium-octeon/crypto/octeon-sha512.c
diff --git a/arch/mips/cavium-octeon/crypto/Makefile
b/arch/mips/cavium-octeon/crypto/Makefile
index 47806a5..f7aa9d5 100644
--- a/arch/mips/cavium-octeon/crypto/Makefile
+++ b/arch/mips/cavium-octeon/crypto/Makefile
@@ -7,3 +7,4 @@ obj-y += octeon-crypto.o
obj-$(CONFIG_CRYPTO_MD5_OCTEON)+= octeon-md5.o
obj-$(CONFIG_CRYPTO_SHA1_OCTEON) += octeon-sha1.o
obj-$(CONFIG_CRYPTO_SHA256_OCTEON) += octeon-sha256.o
+obj-$(CONFIG_CRYPTO_SHA512_OCTEON) += octeon-sha512.o
diff --git a/arch/mips/cavium-octeon/crypto/octeon-sha512.c
b/arch/mips/cavium-octeon/crypto/octeon-sha512.c
new file mode 100644
index 000..d5fb3c6
--- /dev/null
+++ b/arch/mips/cavium-octeon/crypto/octeon-sha512.c
@@ -0,0 +1,277 @@
+/*
+ * Cryptographic API.
+ *
+ * SHA-512 and SHA-384 Secure Hash Algorithm.
+ *
+ * Adapted for OCTEON by Aaro Koskinen aaro.koski...@iki.fi.
+ *
+ * Based on crypto/sha512_generic.c, which is:
+ *
+ * Copyright (c) Jean-Luc Cooke jlco...@certainkey.com
+ * Copyright (c) Andrew McDonald and...@mcdonald.org.uk
+ * Copyright (c) 2003 Kyle McMartin k...@debian.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ */
+
+#include linux/mm.h
+#include crypto/sha.h
+#include linux/init.h
+#include linux/types.h
+#include linux/module.h
+#include asm/byteorder.h
+#include asm/octeon/octeon.h
+#include crypto/internal/hash.h
+
+#include octeon-crypto.h
+
+/*
+ * We pass everything as 64-bit. OCTEON can handle misaligned data.
+ */
+
+static void octeon_sha512_store_hash(struct sha512_state *sctx)
+{
+ write_octeon_64bit_hash_sha512(sctx-state[0], 0);
+ write_octeon_64bit_hash_sha512(sctx-state[1], 1);
+ write_octeon_64bit_hash_sha512(sctx-state[2], 2);
+ write_octeon_64bit_hash_sha512(sctx-state[3], 3);
+ write_octeon_64bit_hash_sha512(sctx-state[4], 4);
+ write_octeon_64bit_hash_sha512(sctx-state[5], 5);
+ write_octeon_64bit_hash_sha512(sctx-state[6], 6);
+ write_octeon_64bit_hash_sha512(sctx-state[7], 7);
+}
+
+static void octeon_sha512_read_hash(struct sha512_state *sctx)
+{
+ sctx-state[0] = read_octeon_64bit_hash_sha512(0);
+ sctx-state[1] = read_octeon_64bit_hash_sha512(1);
+ sctx-state[2] = read_octeon_64bit_hash_sha512(2);
+ sctx-state[3] = read_octeon_64bit_hash_sha512(3);
+ sctx-state[4] = read_octeon_64bit_hash_sha512(4);
+ sctx-state[5] = read_octeon_64bit_hash_sha512(5);
+ sctx-state[6] = read_octeon_64bit_hash_sha512(6);
+ sctx-state[7] = read_octeon_64bit_hash_sha512(7);
+}
+
+static void octeon_sha512_transform(const void *_block)
+{
+ const u64 *block = _block;
+
+ write_octeon_64bit_block_sha512(block[0], 0);
+ write_octeon_64bit_block_sha512(block[1], 1);
+ write_octeon_64bit_block_sha512(block[2], 2);
+ write_octeon_64bit_block_sha512(block[3], 3);
+ write_octeon_64bit_block_sha512(block[4], 4);
+ write_octeon_64bit_block_sha512(block[5], 5);
+ write_octeon_64bit_block_sha512(block[6], 6);
+ write_octeon_64bit_block_sha512(block[7], 7);
+ write_octeon_64bit_block_sha512(block[8], 8);
+ write_octeon_64bit_block_sha512(block[9], 9);
+ write_octeon_64bit_block_sha512(block[10], 10);
+ write_octeon_64bit_block_sha512(block[11], 11);
+ write_octeon_64bit_block_sha512(block[12], 12);
+ write_octeon_64bit_block_sha512(block[13], 13);
+ write_octeon_64bit_block_sha512(block[14], 14);
+ octeon_sha512_start(block[15]);
+}
+
+static int octeon_sha512_init(struct shash_desc *desc)
+{
+ struct sha512_state *sctx = shash_desc_ctx(desc);
+
+ sctx-state[0] = SHA512_H0;
+ sctx-state[1] = SHA512_H1;
+ sctx-state[2] = SHA512_H2;
+ sctx-state[3] = SHA512_H3;
+ sctx-state[4] = SHA512_H4;
+ sctx-state[5] = SHA512_H5;
+ sctx-state[6] = SHA512_H6;
+ sctx-state[7] = SHA512_H7;
+ sctx-count[0] = sctx-count[1] = 0;
+
+ return 0;
+}
+
+static int octeon_sha384_init(struct shash_desc *desc)
+{
+ struct sha512_state *sctx = shash_desc_ctx(desc);
+
+ sctx-state[0] = SHA384_H0;
+ sctx-state[1] = SHA384_H1;
+ sctx-state[2] = SHA384_H2;
+ sctx-state[3] = SHA384_H3;
+ sctx-state[4] = SHA384_H4;
+ sctx-state[5] = SHA384_H5;
+ sctx-state[6] = SHA384_H6;
+ sctx-state[7] = SHA384_H7;
+ sctx-count[0] = sctx-count[1] = 0;
+
+ return 0;
+}
+
+static void __octeon_sha512_update
[PATCH 1/7] crypto: octeon - don't disable bottom half in octeon-md5
Don't disable bottom half while the crypto engine is in use, as it should be unnecessary: All kernel crypto engine usage is wrapped with crypto engine state save/restore, so if we get interrupted by softirq that uses crypto they should save and restore our context. This actually fixes an issue when running OCTEON MD5 with interrupts disabled (tcrypt mode=302). There's a WARNING because the module is trying to enable the bottom half with irqs disabled: [ 52.656610] [ cut here ] [ 52.661439] WARNING: CPU: 1 PID: 428 at /home/aaro/git/linux/kernel/softirq.c:150 __local_bh_enable_ip+0x9c/0xd8() [ 52.671780] Modules linked in: tcrypt(+) [...] [ 52.763539] [8114082c] warn_slowpath_common+0x94/0xd8 [ 52.769465] [81144614] __local_bh_enable_ip+0x9c/0xd8 [ 52.775390] [81119574] octeon_md5_final+0x12c/0x1e8 [ 52.781144] [81337050] shash_compat_digest+0xd0/0x1b0 Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/mips/cavium-octeon/crypto/octeon-md5.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/mips/cavium-octeon/crypto/octeon-md5.c b/arch/mips/cavium-octeon/crypto/octeon-md5.c index b909881..3dd8845 100644 --- a/arch/mips/cavium-octeon/crypto/octeon-md5.c +++ b/arch/mips/cavium-octeon/crypto/octeon-md5.c @@ -97,7 +97,6 @@ static int octeon_md5_update(struct shash_desc *desc, const u8 *data, memcpy((char *)mctx-block + (sizeof(mctx-block) - avail), data, avail); - local_bh_disable(); preempt_disable(); flags = octeon_crypto_enable(state); octeon_md5_store_hash(mctx); @@ -115,7 +114,6 @@ static int octeon_md5_update(struct shash_desc *desc, const u8 *data, octeon_md5_read_hash(mctx); octeon_crypto_disable(state, flags); preempt_enable(); - local_bh_enable(); memcpy(mctx-block, data, len); @@ -133,7 +131,6 @@ static int octeon_md5_final(struct shash_desc *desc, u8 *out) *p++ = 0x80; - local_bh_disable(); preempt_disable(); flags = octeon_crypto_enable(state); octeon_md5_store_hash(mctx); @@ -153,7 +150,6 @@ static int octeon_md5_final(struct shash_desc *desc, u8 *out) octeon_md5_read_hash(mctx); octeon_crypto_disable(state, flags); preempt_enable(); - local_bh_enable(); memcpy(out, mctx-hash, sizeof(mctx-hash)); memset(mctx, 0, sizeof(*mctx)); -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] crypto: octeon - add instruction definitions for SHA1/256/512
Add instruction definitions for SHA1/256/512.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/mips/cavium-octeon/crypto/octeon-crypto.h | 83 --
1 file changed, 79 insertions(+), 4 deletions(-)
diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
index e2a4aec..3550725 100644
--- a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
+++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
@@ -5,7 +5,8 @@
*
* Copyright (C) 2012-2013 Cavium Inc., All Rights Reserved.
*
- * MD5 instruction definitions added by Aaro Koskinen aaro.koski...@iki.fi.
+ * MD5/SHA1/SHA256/SHA512 instruction definitions added by
+ * Aaro Koskinen aaro.koski...@iki.fi.
*
*/
#ifndef __LINUX_OCTEON_CRYPTO_H
@@ -21,11 +22,11 @@ extern void octeon_crypto_disable(struct octeon_cop2_state
*state,
unsigned long flags);
/*
- * Macros needed to implement MD5:
+ * Macros needed to implement MD5/SHA1/SHA256:
*/
/*
- * The index can be 0-1.
+ * The index can be 0-1 (MD5) or 0-2 (SHA1), 0-3 (SHA256).
*/
#define write_octeon_64bit_hash_dword(value, index)\
do { \
@@ -36,7 +37,7 @@ do { \
} while (0)
/*
- * The index can be 0-1.
+ * The index can be 0-1 (MD5) or 0-2 (SHA1), 0-3 (SHA256).
*/
#define read_octeon_64bit_hash_dword(index)\
({ \
@@ -72,4 +73,78 @@ do { \
: [rt] d (value));\
} while (0)
+/*
+ * The value is the final block dword (64-bit).
+ */
+#define octeon_sha1_start(value) \
+do { \
+ __asm__ __volatile__ ( \
+ dmtc2 %[rt],0x4057\
+ : \
+ : [rt] d (value));\
+} while (0)
+
+/*
+ * The value is the final block dword (64-bit).
+ */
+#define octeon_sha256_start(value) \
+do { \
+ __asm__ __volatile__ ( \
+ dmtc2 %[rt],0x404f\
+ : \
+ : [rt] d (value));\
+} while (0)
+
+/*
+ * Macros needed to implement SHA512:
+ */
+
+/*
+ * The index can be 0-7.
+ */
+#define write_octeon_64bit_hash_sha512(value, index) \
+do { \
+ __asm__ __volatile__ ( \
+ dmtc2 %[rt],0x0250+ STR(index)\
+ : \
+ : [rt] d (value));\
+} while (0)
+
+/*
+ * The index can be 0-7.
+ */
+#define read_octeon_64bit_hash_sha512(index) \
+({ \
+ u64 __value;\
+ \
+ __asm__ __volatile__ ( \
+ dmfc2 %[rt],0x0250+ STR(index)\
+ : [rt] =d (__value) \
+ : );\
+ \
+ __value;\
+})
+
+/*
+ * The index can be 0-14.
+ */
+#define write_octeon_64bit_block_sha512(value, index) \
+do { \
+ __asm__ __volatile__ ( \
+ dmtc2 %[rt],0x0240+ STR(index)\
+ : \
+ : [rt] d (value));\
+} while (0)
+
+/*
+ * The value is the final block word (64-bit).
+ */
+#define octeon_sha512_start(value) \
+do { \
+ __asm__ __volatile__ ( \
+ dmtc2 %[rt],0x424f\
+ : \
+ : [rt] d (value));\
+} while (0)
+
#endif /* __LINUX_OCTEON_CRYPTO_H */
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] crypto: octeon - add SHA1 module
Add OCTEON SHA1 module.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/mips/cavium-octeon/crypto/Makefile | 3 +-
arch/mips/cavium-octeon/crypto/octeon-sha1.c | 241 +++
2 files changed, 243 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/cavium-octeon/crypto/octeon-sha1.c
diff --git a/arch/mips/cavium-octeon/crypto/Makefile
b/arch/mips/cavium-octeon/crypto/Makefile
index a74f76d..3f671d6 100644
--- a/arch/mips/cavium-octeon/crypto/Makefile
+++ b/arch/mips/cavium-octeon/crypto/Makefile
@@ -4,4 +4,5 @@
obj-y += octeon-crypto.o
-obj-$(CONFIG_CRYPTO_MD5_OCTEON) += octeon-md5.o
+obj-$(CONFIG_CRYPTO_MD5_OCTEON)+= octeon-md5.o
+obj-$(CONFIG_CRYPTO_SHA1_OCTEON) += octeon-sha1.o
diff --git a/arch/mips/cavium-octeon/crypto/octeon-sha1.c
b/arch/mips/cavium-octeon/crypto/octeon-sha1.c
new file mode 100644
index 000..2b74b5b
--- /dev/null
+++ b/arch/mips/cavium-octeon/crypto/octeon-sha1.c
@@ -0,0 +1,241 @@
+/*
+ * Cryptographic API.
+ *
+ * SHA1 Secure Hash Algorithm.
+ *
+ * Adapted for OCTEON by Aaro Koskinen aaro.koski...@iki.fi.
+ *
+ * Based on crypto/sha1_generic.c, which is:
+ *
+ * Copyright (c) Alan Smithee.
+ * Copyright (c) Andrew McDonald and...@mcdonald.org.uk
+ * Copyright (c) Jean-Francois Dive j...@linuxbe.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include linux/mm.h
+#include crypto/sha.h
+#include linux/init.h
+#include linux/types.h
+#include linux/module.h
+#include asm/byteorder.h
+#include asm/octeon/octeon.h
+#include crypto/internal/hash.h
+
+#include octeon-crypto.h
+
+/*
+ * We pass everything as 64-bit. OCTEON can handle misaligned data.
+ */
+
+static void octeon_sha1_store_hash(struct sha1_state *sctx)
+{
+ u64 *hash = (u64 *)sctx-state;
+ union {
+ u32 word[2];
+ u64 dword;
+ } hash_tail = { { sctx-state[4], } };
+
+ write_octeon_64bit_hash_dword(hash[0], 0);
+ write_octeon_64bit_hash_dword(hash[1], 1);
+ write_octeon_64bit_hash_dword(hash_tail.dword, 2);
+ memzero_explicit(hash_tail.word[0], sizeof(hash_tail.word[0]));
+}
+
+static void octeon_sha1_read_hash(struct sha1_state *sctx)
+{
+ u64 *hash = (u64 *)sctx-state;
+ union {
+ u32 word[2];
+ u64 dword;
+ } hash_tail;
+
+ hash[0] = read_octeon_64bit_hash_dword(0);
+ hash[1] = read_octeon_64bit_hash_dword(1);
+ hash_tail.dword = read_octeon_64bit_hash_dword(2);
+ sctx-state[4] = hash_tail.word[0];
+ memzero_explicit(hash_tail.dword, sizeof(hash_tail.dword));
+}
+
+static void octeon_sha1_transform(const void *_block)
+{
+ const u64 *block = _block;
+
+ write_octeon_64bit_block_dword(block[0], 0);
+ write_octeon_64bit_block_dword(block[1], 1);
+ write_octeon_64bit_block_dword(block[2], 2);
+ write_octeon_64bit_block_dword(block[3], 3);
+ write_octeon_64bit_block_dword(block[4], 4);
+ write_octeon_64bit_block_dword(block[5], 5);
+ write_octeon_64bit_block_dword(block[6], 6);
+ octeon_sha1_start(block[7]);
+}
+
+static int octeon_sha1_init(struct shash_desc *desc)
+{
+ struct sha1_state *sctx = shash_desc_ctx(desc);
+
+ sctx-state[0] = SHA1_H0;
+ sctx-state[1] = SHA1_H1;
+ sctx-state[2] = SHA1_H2;
+ sctx-state[3] = SHA1_H3;
+ sctx-state[4] = SHA1_H4;
+ sctx-count = 0;
+
+ return 0;
+}
+
+static void __octeon_sha1_update(struct sha1_state *sctx, const u8 *data,
+unsigned int len)
+{
+ unsigned int partial;
+ unsigned int done;
+ const u8 *src;
+
+ partial = sctx-count % SHA1_BLOCK_SIZE;
+ sctx-count += len;
+ done = 0;
+ src = data;
+
+ if ((partial + len) = SHA1_BLOCK_SIZE) {
+ if (partial) {
+ done = -partial;
+ memcpy(sctx-buffer + partial, data,
+ done + SHA1_BLOCK_SIZE);
+ src = sctx-buffer;
+ }
+
+ do {
+ octeon_sha1_transform(src);
+ done += SHA1_BLOCK_SIZE;
+ src = data + done;
+ } while (done + SHA1_BLOCK_SIZE = len);
+
+ partial = 0;
+ }
+ memcpy(sctx-buffer + partial, src, len - done);
+}
+
+static int octeon_sha1_update(struct shash_desc *desc, const u8 *data,
+ unsigned int len)
+{
+ struct sha1_state *sctx = shash_desc_ctx(desc);
+ struct octeon_cop2_state state;
+ unsigned long flags;
+
+ /*
+* Small updates never reach the crypto engine, so the generic sha1 is
+* faster
[PATCH 2/7] crypto: octeon - always disable preemption when using crypto engine
Always disable preemption on behalf of the drivers when crypto engine is taken into use. This will simplify the usage. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/mips/cavium-octeon/crypto/octeon-crypto.c | 4 +++- arch/mips/cavium-octeon/crypto/octeon-md5.c| 4 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.c b/arch/mips/cavium-octeon/crypto/octeon-crypto.c index 7c82ff4..f66bd1a 100644 --- a/arch/mips/cavium-octeon/crypto/octeon-crypto.c +++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.c @@ -17,7 +17,7 @@ * crypto operations in calls to octeon_crypto_enable/disable in order to make * sure the state of COP2 isn't corrupted if userspace is also performing * hardware crypto operations. Allocate the state parameter on the stack. - * Preemption must be disabled to prevent context switches. + * Returns with preemption disabled. * * @state: Pointer to state structure to store current COP2 state in. * @@ -28,6 +28,7 @@ unsigned long octeon_crypto_enable(struct octeon_cop2_state *state) int status; unsigned long flags; + preempt_disable(); local_irq_save(flags); status = read_c0_status(); write_c0_status(status | ST0_CU2); @@ -62,5 +63,6 @@ void octeon_crypto_disable(struct octeon_cop2_state *state, else write_c0_status(read_c0_status() ~ST0_CU2); local_irq_restore(flags); + preempt_enable(); } EXPORT_SYMBOL_GPL(octeon_crypto_disable); diff --git a/arch/mips/cavium-octeon/crypto/octeon-md5.c b/arch/mips/cavium-octeon/crypto/octeon-md5.c index 3dd8845..12dccdb 100644 --- a/arch/mips/cavium-octeon/crypto/octeon-md5.c +++ b/arch/mips/cavium-octeon/crypto/octeon-md5.c @@ -97,7 +97,6 @@ static int octeon_md5_update(struct shash_desc *desc, const u8 *data, memcpy((char *)mctx-block + (sizeof(mctx-block) - avail), data, avail); - preempt_disable(); flags = octeon_crypto_enable(state); octeon_md5_store_hash(mctx); @@ -113,7 +112,6 @@ static int octeon_md5_update(struct shash_desc *desc, const u8 *data, octeon_md5_read_hash(mctx); octeon_crypto_disable(state, flags); - preempt_enable(); memcpy(mctx-block, data, len); @@ -131,7 +129,6 @@ static int octeon_md5_final(struct shash_desc *desc, u8 *out) *p++ = 0x80; - preempt_disable(); flags = octeon_crypto_enable(state); octeon_md5_store_hash(mctx); @@ -149,7 +146,6 @@ static int octeon_md5_final(struct shash_desc *desc, u8 *out) octeon_md5_read_hash(mctx); octeon_crypto_disable(state, flags); - preempt_enable(); memcpy(out, mctx-hash, sizeof(mctx-hash)); memset(mctx, 0, sizeof(*mctx)); -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] omap3 crypto fixes
Hi, On Fri, Feb 27, 2015 at 01:40:44PM +0100, Pali Rohár wrote: However I get these when CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set: alg: hash: Chunking test 1 failed for omap-sha1 alg: hash: Chunking test 1 failed for omap-md5 alg: hash: Chunking test 1 failed for omap-hmac-sha1 alg: hash: Chunking test 1 failed for omap-hmac-md5 BTW, it seems these errors are reported to be introduced possibly somewhere between 3.11 and 3.15: https://lists.fedoraproject.org/pipermail/arm/2014-August/008240.html A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/22] parisc: %pF is only for function pointers
Hi, On Thu, Mar 12, 2015 at 02:04:41PM -0400, James Bottomley wrote: On Thu, 2015-03-12 at 11:14 -0500, Scott Wood wrote: On Thu, 2015-03-12 at 08:11 -0400, James Bottomley wrote: On Wed, 2015-03-11 at 22:13 -0500, Scott Wood wrote: Use %pS for actual addresses, otherwise you'll get bad output on arches like ppc64 where %pF expects a function descriptor. Even on other architectures, refrain from setting a bad example that people copy. Are you sure about this? Parisc64 is a function description architecture. There may be a misunderstanding about what __builtin_return_address(0) is supposed to return, but I'm certain the person who added the code thought it returned a function pointer, which on parisc64 would be a descriptor. I wasn't aware that parisc64 used descriptors, but I don't see how you'd get one out of __builtin_return_address(0) since it's not usually a function entry point (plus, GCC documents it as returning void *). I was more thinking that this message is printed for every boot with a superio chip (which is a lot of our boxes). How come no-one has complained on parisc64 if it's doing the wrong thing. It's dead code behind #ifdef DEBUG_SUPERIO_INIT. A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] rtc: __rtc_read_time: reduce log level
__rtc_read_time logs should be debug logs instead of error logs.
For example, when the RTC clock is not set, it's not really useful
to print a kernel error log every time someone tries to read the clock:
~ # hwclock -r
[ 604.508263] rtc rtc0: read_time: fail to read
hwclock: RTC_RD_TIME: Invalid argument
If there's a real error, it's likely that lower level or higher level
code will tell it anyway. Make these logs debug logs, and also print
the error code for the read failure.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/rtc/interface.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 37215cf..c786818 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -31,13 +31,14 @@ static int __rtc_read_time(struct rtc_device *rtc, struct
rtc_time *tm)
memset(tm, 0, sizeof(struct rtc_time));
err = rtc-ops-read_time(rtc-dev.parent, tm);
if (err 0) {
- dev_err(rtc-dev, read_time: fail to read\n);
+ dev_dbg(rtc-dev, read_time: fail to read: %d\n,
+ err);
return err;
}
err = rtc_valid_tm(tm);
if (err 0)
- dev_err(rtc-dev, read_time: rtc_time isn't valid\n);
+ dev_dbg(rtc-dev, read_time: rtc_time isn't valid\n);
}
return err;
}
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] rtc: initialize rtc name early
In some error cases RTC name is used before it is initialized: rtc-rs5c372 0-0032: clock needs to be set rtc-rs5c372 0-0032: rs5c372b found, 24hr, driver version 0.6 rtc (null): read_time: fail to read rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0 Fix by initializing the name early. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- drivers/rtc/class.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c index 472a5ad..014ecbc 100644 --- a/drivers/rtc/class.c +++ b/drivers/rtc/class.c @@ -225,15 +225,15 @@ struct rtc_device *rtc_device_register(const char *name, struct device *dev, rtc-pie_timer.function = rtc_pie_update_irq; rtc-pie_enabled = 0; + strlcpy(rtc-name, name, RTC_DEVICE_NAME_SIZE); + dev_set_name(rtc-dev, rtc%d, id); + /* Check to see if there is an ALARM already set in hw */ err = __rtc_read_alarm(rtc, alrm); if (!err !rtc_valid_tm(alrm.time)) rtc_initialize_alarm(rtc, alrm); - strlcpy(rtc-name, name, RTC_DEVICE_NAME_SIZE); - dev_set_name(rtc-dev, rtc%d, id); - rtc_dev_prepare(rtc); err = device_register(rtc-dev); -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] rtc: hctosys: use function name in the error log
Use function name in the error log instead of __FILE__.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/rtc/hctosys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
index 6c719f2..7748a61 100644
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -33,7 +33,7 @@ static int __init rtc_hctosys(void)
if (rtc == NULL) {
pr_err(%s: unable to open rtc device (%s)\n,
- __FILE__, CONFIG_RTC_HCTOSYS_DEVICE);
+ __func__, CONFIG_RTC_HCTOSYS_DEVICE);
goto err_open;
}
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] mfd: menelaus: delete omap_has_menelaus
Delete unused macro. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- include/linux/mfd/menelaus.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h index f097e89..a1e12bf3 100644 --- a/include/linux/mfd/menelaus.h +++ b/include/linux/mfd/menelaus.h @@ -38,10 +38,4 @@ extern int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV); extern int menelaus_set_regulator_sleep(int enable, u32 val); -#if defined(CONFIG_ARCH_OMAP2) defined(CONFIG_MENELAUS) -#define omap_has_menelaus()1 -#else -#define omap_has_menelaus()0 -#endif - #endif -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] mfd: menelaus: use macro for magic number
Use macro to check a register bit. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- drivers/mfd/menelaus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c index 917fa86..c2ca665 100644 --- a/drivers/mfd/menelaus.c +++ b/drivers/mfd/menelaus.c @@ -1216,7 +1216,7 @@ static int menelaus_probe(struct i2c_client *client, err = menelaus_read_reg(MENELAUS_VCORE_CTRL1); if (err 0) goto fail; - if (err BIT(7)) + if (err VCORE_CTRL1_HW_NSW) menelaus-vcore_hw_mode = 1; else menelaus-vcore_hw_mode = 0; -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mfd: menelaus: drop support for SW controller VCORE
Drop support for SW controlled VCORE, nobody uses it.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/mfd/menelaus.c | 23 ---
include/linux/mfd/menelaus.h | 1 -
2 files changed, 24 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 9f01aef..917fa86 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -532,29 +532,6 @@ static const struct menelaus_vtg_value vcore_values[] = {
{ 1450, 18 },
};
-int menelaus_set_vcore_sw(unsigned int mV)
-{
- int val, ret;
- struct i2c_client *c = the_menelaus-client;
-
- val = menelaus_get_vtg_value(mV, vcore_values,
-ARRAY_SIZE(vcore_values));
- if (val 0)
- return -EINVAL;
-
- dev_dbg(c-dev, Setting VCORE to %d mV (val 0x%02x)\n, mV, val);
-
- /* Set SW mode and the voltage in one go. */
- mutex_lock(the_menelaus-lock);
- ret = menelaus_write_reg(MENELAUS_VCORE_CTRL1, val);
- if (ret == 0)
- the_menelaus-vcore_hw_mode = 0;
- mutex_unlock(the_menelaus-lock);
- msleep(1);
-
- return ret;
-}
-
int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV)
{
int fval, rval, val, ret;
diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
index a1e12bf3..9e85ac0 100644
--- a/include/linux/mfd/menelaus.h
+++ b/include/linux/mfd/menelaus.h
@@ -24,7 +24,6 @@ extern int menelaus_set_vaux(unsigned int mV);
extern int menelaus_set_vdcdc(int dcdc, unsigned int mV);
extern int menelaus_set_slot_sel(int enable);
extern int menelaus_get_slot_pin_states(void);
-extern int menelaus_set_vcore_sw(unsigned int mV);
extern int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV);
#define EN_VPLL_SLEEP (1 7)
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] mfd: menelaus: couple simple cleanups
Hi, I came across these while trying to start DT conversion for menelaus (http://marc.info/?t=14197028735r=1w=2). While the DT work failed and is still pending, I think it's still worth to apply these as they are independent and they remove some cruft from the tree. A. Aaro Koskinen (3): mfd: menelaus: delete omap_has_menelaus mfd: menelaus: drop support for SW controller VCORE mfd: menelaus: use macro for magic number drivers/mfd/menelaus.c | 25 + include/linux/mfd/menelaus.h | 7 --- 2 files changed, 1 insertion(+), 31 deletions(-) -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] README: Update references to version 4
Hi, On Sat, Mar 28, 2015 at 11:46:30PM -0400, Pranith Kumar wrote: Since we bumped the version to 4.0, let us update the references to match that in the README file. Documentation/HOWTO seems to have plenty of references to 3.x as well... A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/2] HSI: nokia-modem: Add cmt-speech support
Hi, On Sat, Mar 21, 2015 at 08:09:17PM +0100, Sebastian Reichel wrote: Register cmt-speech driver in nokia-modem driver and forward hsi channel information. Signed-off-by: Sebastian Reichel s...@kernel.org Acked-by: Aaro Koskinen aaro.koski...@iki.fi A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/2] HSI: cmt_speech: Add cmt-speech driver
Hi, On Sat, Mar 21, 2015 at 08:09:16PM +0100, Sebastian Reichel wrote: From: Kai Vehmanen kai.vehma...@nokia.com Introduces the cmt-speech driver, which implements a character device interface for transferring speech data frames over HSI/SSI. The driver is used to exchange voice/speech data between the Nokia N900/N950/N9's modem and its cpu. Signed-off-by: Kai Vehmanen kai.vehma...@nokia.com Signed-off-by: Carlos Chinea carlos.chi...@nokia.com Signed-off-by: Joni Lapilainen joni.lapilai...@gmail.com Acked-by: Aaro Koskinen aaro.koski...@iki.fi A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
