Socfpga 3.10 ltsi de0 nano with tft #405

ngalbo · 2017-04-18T23:29:31Z

No description provided.

Modify device tree for multiple interrupt parameters. Add DMA files which combine multiple DMA irqs into one. Add platform data structure. Modify pl330 driver, less intrusive modifications for multiple IRQs. Remove AMBA_NR_IRQS modification. Document devicetree bindings. Signed-off-by: Graham Moore <[email protected]>

Set 3-byte addressing mode upon shutdown. Devicetree changes for n25q512 device. Signed-off-by: Graham Moore <[email protected]>

Update the baudrate in the bootargs of the chosen node in the DTS entry. Also modify the default bootargs to use SD for the rootfs. Signed-off-by: Dinh Nguyen <[email protected]> --- v2: - Add change for socfpga_arria5.dts

Change platform code so that emacs are left in reset until initialized. Signed-off-by: Graham Moore <[email protected]>

Set chip select value before using it as index into array. Signed-off-by: Graham Moore <[email protected]>

The community C_CAN/D_CAN driver works with the SoCFPGA CycloneV board but requires a few changes to the Altera SoCFPGA device tree. Add changes to socfpga.dtsi : - Update of IRQs (needed to add the CAN Message Object IRQ. - Define the CAN clocks - Leave CAN0 and CAN1 disabled. Add changes to socfpga_cyclone5.dts - Turn on CAN0 on Cyclone5 boards. CAN should be compiled into kernel for Altera SoCFPGA. - Configure CAN by default in socfpga_defconfig Signed-off-by: Thor Thayer <[email protected]>

We should backup SP register before SAVE_SWITCH_STACK macro in sys_rt_sigreturn() because SP register is being modified in SAVE_SWITCH_STACK macro. Signed-off-by: Ley Foon Tan <[email protected]>

For clocks with a fixed-divider, the "reg" parameter is not necessary. The mpu_periph_clk does not have a gate, so change it to the type "altr,socfpga-perip-clk". Set the proper clock for the smp_twd timer in the device tree entry. By doing this, revert the fix in kernel/smp_twd.c to match kernel.org. Signed-off-by: Dinh Nguyen <[email protected]>

udev is required by Angstrom, which is our target Linux distribution. The relevant kernel config options, for udev versions later than 141, are listed on kernel.org: CONFIG_DEVTMPFS=y CONFIG_HOTPLUG=y CONFIG_INOTIFY_USER=y CONFIG_NET=y CONFIG_PROC_FS=y CONFIG_SIGNALFD=y CONFIG_SYSFS=y CONFIG_SYSFS_DEPRECATED*=n CONFIG_UEVENT_HELPER_PATH="" This patch was tested against the Angstrom and Yocto RFS'es V2: removed CONFIG_SYSFS_DEPRECATED=n Signed-off-by: Yves Vandervennet <[email protected]>

The kernel build for SOCFPGA was broken when building CONFIG_SMP is disabled. The error is in the Kconfig for SOCFPGA, as it should only build the ARM TWD timer if CONFIG_SMP is enabled. Signed-off-by: Dinh Nguyen <[email protected]>

The register offsets for D_CAN1 were incorrect in the socfpga.dtsi file. - Change from incorrect offset 0xFFC10000 to 0xFFC01000. Signed-off-by: Thor Thayer <[email protected]>

Revert FogBugz #155744 (commit d4db2a9db6). Restore back to original code. This is because do_rt_sigreturn() takes a struct switch_stack* as argument. So, we should load SP after SAVE_SWITCH_STACK. asmlinkage int do_rt_sigreturn(struct switch_stack *sw); Signed-off-by: Ley Foon Tan <[email protected]>

This change enables VLAN tagging to work with the vconfig utility. See FogBugz #162656 for more details about adding vconfig to the default file system. Signed-off-by: Vince Bridgers <[email protected]>

…g of receive buffers The root causes for the Jumbo frame problems seen were: 1) The driver was enabling Jumbo frames up to 9018 bytes in length (MTU = 9000) without allocating the correct amount of receive buffer space. When the controller received a packet larger than the smaller receive buffer, the controller's DMA overwrote kernel memory, causing code/data corruption eventually leading to a kernel crash. 2) The driver was not setting the correct DMA mapping length before mapping receive buffers. This led to a subsequent unmapping operation using an incorrect mapping length with respect to the one used for mapping. As long as the user did not bring down then up the driver, there was no problem. This problem only showed up as a result of testing MTU changes by cycling the interface up and down through different MTUs. The fixes implemented for these problems were: 1) Add configuration parameter in the device tree for maximum Jumbo frame size. This is needed since the transmit and receive fifos sizes are configurable when the cores are created through Synopsys Core Consultant. Having this parameter allows DMA I/O memory to be conserved as much as possible by only allocating what's required for packet receives. Example: If the MTU was set to 9000 and the transmit and receive fifos were set to 4096 bytes, then a receive buffer size of 16K would be used when only 4096 is required. The valid range for the C5 SOC is 2000 through 4062, inclusive. 2) Update Documentation text file for stmmac parameters by adding "snps,max-mtu" See 1) above for details. 3) Changes to handle proper range checking of MTU in stmmac_change_mtu 4) Use correct DMA buffer length when allocating receive buffers 5) Default Configuration Register 0 settings were changed to not enable Jumbo frame by default. 802.3as frame size expansion is enabled by default, and Jumbo frame is enabled only if MTU size is set for Jumbo frames. This permits receive buffer size allocation per current MTU settings. 6) DMA buffer sizes are properly sized for the maximum MTU size configured. Signed-off-by: Vince Bridgers <[email protected]> Conflicts: arch/arm/boot/dts/socfpga_cyclone5.dts

Firmware to support the EDAC framework for the SDRAM ECC on the Altera CycloneV board is added in this patch. - The SDRAM Controller registers are used by the FPGA bridge so these are accessed through the syscon interface. - The interrupts are included in the sdramedac device tree node and accessed with the platform functions. - The configuration of the SDRAM memory size for the EDAC framework is discovered from the memory node of the device tree. - Documentation of the bindings in devicetree/bindings/arm/altera V2: Implement review changes. - Fix copyright. - Call edac_mc_free() if error on devres_open_group(). - Remove pr_debugs. - Fix spacing in calculation for readability. - Add platform_set_drvdata() in alt_sdram_mc_remove(). - Add of_match_ptr() around .of_match_table element. V3: - Replace pr_debug() with dev_dbg(). - Remove /r line endings. V4: - Check return code of regmap_read() in probe. V5: - Clear regmap_read() variables before use. - Check return code when looking for memory size. - Include attribution in copyright. - Enable IRQ after successfully adding memory controller. V6: - Rename functions and macros from ALT to ALTR - Cleanup of code to reflect Linux conventions. - Replace MODULE_ALIAS with MODULE_AUTHOR("Altera Corporation"); Signed-off-by: Thor Thayer <[email protected]>

The community Memory Mapped Designware SPI driver is not currently documented so it is added here. V2: Use generic interrupt description instead of GIC specific. V3: Cleanup of extra lines & compatible description. V4: Addition of clock source. Signed-off-by: Thor Thayer <[email protected]>

This patch addresses a few bugs and features in the Denali NAND driver on the socfpga platform. First the bugs: - Reading ONFI parameters would cause a timeout, because the code sent the wrong commands to the controller/device. That was fixed, and in the process, code was added to wait for the appropriate interrupt. - When using the JFFS2 file system, a bug was discovered in the write OOB data function, whereby the controller was left in SPARE mode causing subsequent page reads to fail. The write OOB function was modified so that the controller is left in MAIN access mode. Now the features: - The Denali NAND controller in the socfpga platform has hardware ECC, and several status bits are different because of that. A patch from Jamie Iles <jamie at jamieiles.com> was used as the basis for supporting hardware ECC in the code. - The device tree and documentation were modified to support hardware ECC. - One of our test socfpga boards had a NAND chip which was locked by default. To support writing to the chip, the UNLOCK1 and UNLOCK2 commands were implemented. The nand_unlock calls were added as well. (Note, the mtd layer has _lock, _unlock, and is probably a better place to implement this functionality than the nand driver). - The mtd_device_register call was replaced with mtd_device_parse_register so that device tree partitions are setup by the mtd layer. Example partitions were added to the device tree. - In the process of supporting our specific controller configuration, duplicate definitions of bad block table descriptions were removed from the denali code. They also exist in the nand driver code. Signed-off-by: Graham Moore <[email protected]>

If the supplied DTB is builtin into kernel, it is in __init memory and will eventually be destroyed after bootup. But if drivers are loaded as modules, they still need to access the DTB entries after the kernel has started. Therefore, the DTB is moved to a new allocated area. Thanks Jeroen Van den Keybus for the fix. Signed-off-by: Ley Foon Tan <[email protected]>

The read, write, and command ports on the fpga2sdram bridge can only be reconfigured if there are no transactions to the sdram during the reconfiguration. Currently, this guarantee can only be made by code running out of onchip ram before Linux is started. Therefore, this driver only supports enabling and disabling of the ports that have already been configured. Since the driver cannot determine the port configuration in all cases, the device tree must be populated with masks for all of the ports. Signed-off-by: Matthew Gerlach <[email protected]>

The current SDRAM ECC testing was performed by shorting an address line to ground. In the case of an uncorrectable error (2 bit error) 2 address lines had to be shorted to ground. The Altera SDRAM controller has the ability to inject ECC errors (single or double bit) during write operations. This change implements the injection of SDRAM ECC errors in software. - Requires that EDAC debugging (CONFIG_EDAC_DEBUG) is defined. - Single or double bit errors are generated depending upon string size sent (1 character = 1 bit error/2 char=2bit) - To inject a single bit error (correctable) echo "1" > /sys/kernel/debug/edac/mc0/inject_ctl - To inject a double bit error (uncorrectable - panic) echo "12" > /sys/kernel/debug/edac/mc0/inject_ctl V2: - Make double bit error case very restrictive Signed-off-by: Thor Thayer <[email protected]>

The fpga bridge framework needs be started before the individual bridge drivers, and the individual bridge drivers need to be started before any other driver for components on the FPGA. The earliest the bridge drivers successfully start is during arch_init(). Signed-off-by: Matthew Gerlach <[email protected]>

The IPv6 option needs to be specific in socfpga_defconfig for IPv6 networking to be available in the Linux networking stack. Signed-off-by: Vince Bridgers <[email protected]>

Enable DEVTMFS as default and removed non-exist configs. CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y Note, need to compile rootfs with BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS enabled. Signed-off-by: Ley Foon Tan <[email protected]>

Fix boot from flash issue. .GOT section needs to be after .text section because arch/nios2/boot/compressed/misc.c:decompress_kernel() assumes kernel is at top of the memory region. Signed-off-by: Ley Foon Tan <[email protected]>

Updated calls to device_prep_slave_sg() because the parameter list had changed since the last time spi-dw-pl330.c was compiled. Signed-off-by: Graham Moore <[email protected]>

Support for DMA transfers was added to the Cadence QSPI driver. There is a fair amount of new code, but the flow of the driver was minimally changed. If the code is unable to initialize DMA channels, it falls back to non-DMA operation. Enabling of the DMA transfers is done through the device tree. Peripheral Request IDs for the QSPI are specified in the device tree. Device tree documentation was updated. V2: Check error return from device_prep_slave_sg Use #defines for request byte counts Replaced pr_debug/pr_err with dev_dbg/dev_err Signed-off-by: Graham Moore <[email protected]>

The merge to version 3.12 duplicated device flags 0x08 and 0x10, resulting in incorrect behavior on CycloneV. The fix was to change the definitions of USE_FSR and SHUTDOWN_3BYTE flags to 0x20 and 0x40. Signed-off-by: Graham Moore <[email protected]> Conflicts: drivers/mtd/devices/m25p80.c

Remove unused Samsung-specific machine include and Kconfig dependency on S3C. Signed-off-by: Matt Porter <[email protected]> Reviewed-by: Markus Mayer <[email protected]> Reviewed-by: Tim Kryger <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>

Enable support for the dwc2 binding. Signed-off-by: Matt Porter <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Conflicts: drivers/usb/gadget/s3c-hsotg.c

For device removal and replace we call btrfs_find_device_by_devspec, which if we give it a device path and nothing else will call btrfs_get_dev_args_from_path, which opens the block device and reads the super block and then looks up our device based on that. However at this point we're holding the sb write "lock", so reading the block device pulls in the dependency of ->open_mutex, which produces the following lockdep splat ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc2+ torvalds#405 Not tainted ------------------------------------------------------ losetup/11576 is trying to acquire lock: ffff9bbe8cded938 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x67/0x5e0 but task is already holding lock: ffff9bbe88e4fc68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&lo->lo_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 lo_open+0x28/0x60 [loop] blkdev_get_whole+0x25/0xf0 blkdev_get_by_dev.part.0+0x168/0x3c0 blkdev_open+0xd2/0xe0 do_dentry_open+0x161/0x390 path_openat+0x3cc/0xa20 do_filp_open+0x96/0x120 do_sys_openat2+0x7b/0x130 __x64_sys_openat+0x46/0x70 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #3 (&disk->open_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 blkdev_get_by_dev.part.0+0x56/0x3c0 blkdev_get_by_path+0x98/0xa0 btrfs_get_bdev_and_sb+0x1b/0xb0 btrfs_find_device_by_devspec+0x12b/0x1c0 btrfs_rm_device+0x127/0x610 btrfs_ioctl+0x2a31/0x2e70 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #2 (sb_writers#12){.+.+}-{0:0}: lo_write_bvec+0xc2/0x240 [loop] loop_process_work+0x238/0xd00 [loop] process_one_work+0x26b/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}: process_one_work+0x245/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #0 ((wq_completion)loop0){+.+.}-{0:0}: __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 flush_workqueue+0x91/0x5e0 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&lo->lo_mutex); lock(&disk->open_mutex); lock(&lo->lo_mutex); lock((wq_completion)loop0); *** DEADLOCK *** 1 lock held by losetup/11576: #0: ffff9bbe88e4fc68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] stack backtrace: CPU: 0 PID: 11576 Comm: losetup Not tainted 5.14.0-rc2+ torvalds#405 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack_lvl+0x57/0x72 check_noncircular+0xcf/0xf0 ? stack_trace_save+0x3b/0x50 __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 ? flush_workqueue+0x67/0x5e0 ? lockdep_init_map_type+0x47/0x220 flush_workqueue+0x91/0x5e0 ? flush_workqueue+0x67/0x5e0 ? verify_cpu+0xf0/0x100 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] ? blkdev_ioctl+0x8d/0x2a0 block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f31b02404cb Instead what we want to do is populate our device lookup args before we grab any locks, and then pass these args into btrfs_rm_device(). From there we can find the device and do the appropriate removal. Suggested-by: Anand Jain <[email protected]> Reviewed-by: Anand Jain <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]>

[ Upstream commit 1a15eb7 ] For device removal and replace we call btrfs_find_device_by_devspec, which if we give it a device path and nothing else will call btrfs_get_dev_args_from_path, which opens the block device and reads the super block and then looks up our device based on that. However at this point we're holding the sb write "lock", so reading the block device pulls in the dependency of ->open_mutex, which produces the following lockdep splat ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc2+ torvalds#405 Not tainted ------------------------------------------------------ losetup/11576 is trying to acquire lock: ffff9bbe8cded938 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x67/0x5e0 but task is already holding lock: ffff9bbe88e4fc68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&lo->lo_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 lo_open+0x28/0x60 [loop] blkdev_get_whole+0x25/0xf0 blkdev_get_by_dev.part.0+0x168/0x3c0 blkdev_open+0xd2/0xe0 do_dentry_open+0x161/0x390 path_openat+0x3cc/0xa20 do_filp_open+0x96/0x120 do_sys_openat2+0x7b/0x130 __x64_sys_openat+0x46/0x70 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #3 (&disk->open_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 blkdev_get_by_dev.part.0+0x56/0x3c0 blkdev_get_by_path+0x98/0xa0 btrfs_get_bdev_and_sb+0x1b/0xb0 btrfs_find_device_by_devspec+0x12b/0x1c0 btrfs_rm_device+0x127/0x610 btrfs_ioctl+0x2a31/0x2e70 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #2 (sb_writers#12){.+.+}-{0:0}: lo_write_bvec+0xc2/0x240 [loop] loop_process_work+0x238/0xd00 [loop] process_one_work+0x26b/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}: process_one_work+0x245/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #0 ((wq_completion)loop0){+.+.}-{0:0}: __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 flush_workqueue+0x91/0x5e0 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&lo->lo_mutex); lock(&disk->open_mutex); lock(&lo->lo_mutex); lock((wq_completion)loop0); *** DEADLOCK *** 1 lock held by losetup/11576: #0: ffff9bbe88e4fc68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] stack backtrace: CPU: 0 PID: 11576 Comm: losetup Not tainted 5.14.0-rc2+ torvalds#405 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack_lvl+0x57/0x72 check_noncircular+0xcf/0xf0 ? stack_trace_save+0x3b/0x50 __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 ? flush_workqueue+0x67/0x5e0 ? lockdep_init_map_type+0x47/0x220 flush_workqueue+0x91/0x5e0 ? flush_workqueue+0x67/0x5e0 ? verify_cpu+0xf0/0x100 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] ? blkdev_ioctl+0x8d/0x2a0 block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f31b02404cb Instead what we want to do is populate our device lookup args before we grab any locks, and then pass these args into btrfs_rm_device(). From there we can find the device and do the appropriate removal. Suggested-by: Anand Jain <[email protected]> Reviewed-by: Anand Jain <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

…h cpu=v4 Bpf cpu=v4 support is introduced in [1] and Commit 4cd58e9 ("bpf: Support new 32bit offset jmp instruction") added support for new 32bit offset jmp instruction. Unfortunately, in function bpf_adj_delta_to_off(), for new branch insn with 32bit offset, the offset (plus/minor a small delta) compares to 16-bit offset bound [S16_MIN, S16_MAX], which caused the following verification failure: $ ./test_progs-cpuv4 -t verif_scale_pyperf180 ... insn 10 cannot be patched due to 16-bit range ... libbpf: failed to load object 'pyperf180.bpf.o' scale_test:FAIL:expect_success unexpected error: -12 (errno 12) torvalds#405 verif_scale_pyperf180:FAIL Note that due to recent llvm18 development, the patch [2] (already applied in bpf-next) needs to be applied to bpf tree for testing purpose. The fix is rather simple. For 32bit offset branch insn, the adjusted offset compares to [S32_MIN, S32_MAX] and then verification succeeded. [1] https://lore.kernel.org/all/[email protected] [2] https://lore.kernel.org/bpf/[email protected] Fixes: 4cd58e9 ("bpf: Support new 32bit offset jmp instruction") Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]

…h cpu=v4 [ Upstream commit dfce9cb ] Bpf cpu=v4 support is introduced in [1] and Commit 4cd58e9 ("bpf: Support new 32bit offset jmp instruction") added support for new 32bit offset jmp instruction. Unfortunately, in function bpf_adj_delta_to_off(), for new branch insn with 32bit offset, the offset (plus/minor a small delta) compares to 16-bit offset bound [S16_MIN, S16_MAX], which caused the following verification failure: $ ./test_progs-cpuv4 -t verif_scale_pyperf180 ... insn 10 cannot be patched due to 16-bit range ... libbpf: failed to load object 'pyperf180.bpf.o' scale_test:FAIL:expect_success unexpected error: -12 (errno 12) torvalds#405 verif_scale_pyperf180:FAIL Note that due to recent llvm18 development, the patch [2] (already applied in bpf-next) needs to be applied to bpf tree for testing purpose. The fix is rather simple. For 32bit offset branch insn, the adjusted offset compares to [S32_MIN, S32_MAX] and then verification succeeded. [1] https://lore.kernel.org/all/[email protected] [2] https://lore.kernel.org/bpf/[email protected] Fixes: 4cd58e9 ("bpf: Support new 32bit offset jmp instruction") Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>

…h cpu=v4 commit dfce9cb upstream. Bpf cpu=v4 support is introduced in [1] and Commit 4cd58e9 ("bpf: Support new 32bit offset jmp instruction") added support for new 32bit offset jmp instruction. Unfortunately, in function bpf_adj_delta_to_off(), for new branch insn with 32bit offset, the offset (plus/minor a small delta) compares to 16-bit offset bound [S16_MIN, S16_MAX], which caused the following verification failure: $ ./test_progs-cpuv4 -t verif_scale_pyperf180 ... insn 10 cannot be patched due to 16-bit range ... libbpf: failed to load object 'pyperf180.bpf.o' scale_test:FAIL:expect_success unexpected error: -12 (errno 12) torvalds#405 verif_scale_pyperf180:FAIL Note that due to recent llvm18 development, the patch [2] (already applied in bpf-next) needs to be applied to bpf tree for testing purpose. The fix is rather simple. For 32bit offset branch insn, the adjusted offset compares to [S32_MIN, S32_MAX] and then verification succeeded. [1] https://lore.kernel.org/all/[email protected] [2] https://lore.kernel.org/bpf/[email protected] Fixes: 4cd58e9 ("bpf: Support new 32bit offset jmp instruction") Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

Graham Moore and others added 30 commits February 25, 2014 10:06

FogBugz #131467: Software COLD QSPI reset

45934bd

Set 3-byte addressing mode upon shutdown. Devicetree changes for n25q512 device. Signed-off-by: Graham Moore <[email protected]>

FogBugz #153767: Update baudrate in DTS for SOCFPGA

41c8cf6

Update the baudrate in the bootargs of the chosen node in the DTS entry. Also modify the default bootargs to use SD for the rootfs. Signed-off-by: Dinh Nguyen <[email protected]> --- v2: - Add change for socfpga_arria5.dts

FogBugz #128180: Fix emac reset and phy-select sequence.

4bfbf9c

Change platform code so that emacs are left in reset until initialized. Signed-off-by: Graham Moore <[email protected]>

FogBugz #152777: Fix out-of-order QSPI chip select configuration.

0025396

Set chip select value before using it as index into array. Signed-off-by: Graham Moore <[email protected]>

FogBugz #155744: arch/nios2: Backup SP before SAVE_SWITCH_STACK

af4a01a

We should backup SP register before SAVE_SWITCH_STACK macro in sys_rt_sigreturn() because SP register is being modified in SAVE_SWITCH_STACK macro. Signed-off-by: Ley Foon Tan <[email protected]>

FogBugz #138919: Fixes for Linux CAN Support

3ff5718

The register offsets for D_CAN1 were incorrect in the socfpga.dtsi file. - Change from incorrect offset 0xFFC10000 to 0xFFC01000. Signed-off-by: Thor Thayer <[email protected]>

Fix up m25p80

3c22510

FogBugz #162387: Add config options to defconfig to support VLAN tagging

bcbbec1

This change enables VLAN tagging to work with the vconfig utility. See FogBugz #162656 for more details about adding vconfig to the default file system. Signed-off-by: Vince Bridgers <[email protected]>

FogBugz #166582: Kernel needs option to support IPv6

6a8d164

The IPv6 option needs to be specific in socfpga_defconfig for IPv6 networking to be available in the Linux networking stack. Signed-off-by: Vince Bridgers <[email protected]>

FogBugz #166244: Compilation error in spi-dw-pl330.c

c9ba014

Updated calls to device_prep_slave_sg() because the parameter list had changed since the last time spi-dw-pl330.c was compiled. Signed-off-by: Graham Moore <[email protected]>

usb: gadget: s3c-hsotg: add snps,dwc2 compatible string

e87322a

Enable support for the dwc2 binding. Signed-off-by: Matt Porter <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Conflicts: drivers/usb/gadget/s3c-hsotg.c

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Socfpga 3.10 ltsi de0 nano with tft #405

Socfpga 3.10 ltsi de0 nano with tft #405

ngalbo commented Apr 18, 2017

Socfpga 3.10 ltsi de0 nano with tft #405

Are you sure you want to change the base?

Socfpga 3.10 ltsi de0 nano with tft #405

Conversation

ngalbo commented Apr 18, 2017