Re: [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts

On Tue, Apr 20, 2021 at 02:37:10PM -0600, dann frazier wrote: > On Tue, May 19, 2020 at 05:17:52PM +0100, Marc Zyngier wrote: > > Change the way we deal with GIC SGIs by turning them into proper > > IRQs, and calling into the arch code to register the interrupt range > >

Re: [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts

On Tue, May 19, 2020 at 05:17:52PM +0100, Marc Zyngier wrote: > Change the way we deal with GIC SGIs by turning them into proper > IRQs, and calling into the arch code to register the interrupt range > instead of a callback. > > Signed-off-by: Marc Zyngier hey Marc, I bisected a boot failure

Re: [PATCH] PCI: xgene: fix a mistake about cfg address

variable, So after this commit, the port->cfg_addr > will get a wrong address. Now, revert it. > > Fixes: e2dcd20b1645a ("PCI: controller: Convert to > devm_platform_ioremap_resource_byname()") > Reported-by: dann.fraz...@canonical.com > Signed-off-by: Dejin Zheng

Re: [PATCH v2] PCI: controller: convert to devm_platform_ioremap_resource_byname()

On Wed, Jun 03, 2020 at 01:16:01AM +0800, Dejin Zheng wrote: > Use devm_platform_ioremap_resource_byname() to simplify codes. > it contains platform_get_resource_byname() and devm_ioremap_resource(). > > Signed-off-by: Dejin Zheng > --- > v1 -> v2: > - Discard changes to the file

Re: [PATCH 4.4 17/70] crypto: arm64/sha - avoid non-standard inline asm tricks

On Mon, Nov 23, 2020 at 01:49:07PM -0700, dann frazier wrote: > On Mon, Nov 26, 2018 at 11:50:32AM +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > fyi, I bisected a regression down to this commit. This appa

Re: [PATCH 4.4 17/70] crypto: arm64/sha - avoid non-standard inline asm tricks

On Mon, Nov 26, 2018 at 11:50:32AM +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. fyi, I bisected a regression down to this commit. This apparently causes an ADR_PREL_PG_HI21 relocation to be added to the sha{1,2}_ce modules. Back in

5.9-rc7 oops in nvkm_udevice_info() w/ GA100

hey, I'm seeing an Oops when nouveau loads (see below). I've verified that this is because both device->chip and device->name are NULL prior to the strncpy()s at the end of nvkm_udevice_info(). Bisect shows that this started happening after: commit 24d5ff40a732633dceab68c6559ba723784f4a68

Re: [for-next][PATCH 09/18] tracing: Move pipe reference to trace array instead of current_tracer

On Fri, Jul 31, 2020 at 3:16 PM Steven Rostedt wrote: > > On Fri, 31 Jul 2020 13:33:45 -0600 > dann frazier wrote: > > > > This is marked as "Fixes" but is more of a clean up than a true fix. > > > Backport if you want, but its not critical. > >

Re: [for-next][PATCH 09/18] tracing: Move pipe reference to trace array instead of current_tracer

On Thu, Jul 02, 2020 at 05:58:21PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > If a process has the trace_pipe open on a trace_array, the current tracer > for that trace array should not be changed. This was original enforced by a > global lock, but when instances were

Re: [PATCH net-next] hinic: fix a bug in set rx mode

On Mon, May 27, 2019 at 10:10:05PM +, Xue Chaojing wrote: > in set_rx_mode, __dev_mc_sync and netdev_for_each_mc_addr will > repeatedly set the multicast mac address. so we delete this loop. fyi, I'm told this fixes the following Oops (in case it makes sense to queue it for stable): [

Re: [PATCH] ixgbe: Avoid NULL pointer dereference with VF on non-IPsec hw

hey David, Jeff - is it possible to get this queued up as a fix for 5.2? -dann On Wed, May 22, 2019 at 05:22:58PM -0600, dann frazier wrote: > An ipsec structure will not be allocated if the hardware does not support > offload. Fixes the following Oops: > > [ 191.045452] Unab

[PATCH] ixgbe: Avoid NULL pointer dereference with VF on non-IPsec hw

[ 191.378077] cpu_startup_entry+0x2c/0x30 [ 191.381988] secondary_start_kernel+0x150/0x1e0 [ 191.386506] Code: 6b15003f 54000320 f1404a9f 5460 (79400260) Fixes: eda0333ac2930 ("ixgbe: add VF IPsec management") Signed-off-by: dann frazier --- drivers/net/ethernet/intel/ixgbe/ixgbe_i

Re: [PATCH] scsi: libsas: Fix rphy phy_identifier for PHYs with end devices attached

aaa1f-phy8-lun-0-part1 -> ../../sdf1 > lrwxrwxrwx 1 root root 10 Feb 13 11:53 > platform-HISI0162:01-sas-exp0x500e004aaa1f-phy8-lun-0-part2 -> ../../sdf2 > lrwxrwxrwx 1 root root 10 Feb 13 11:53 > platform-HISI0162:01-sas-exp0x500e004aaa1f-phy8-lun-0-part3 -> ../../sd

Re: [PATCH net-next] net: hns3: Config NIC port speed same as that of optical module

On Wed, Jan 02, 2019 at 08:45:36PM +0800, lipeng (Y) wrote: > > > On 2019/1/1 9:22, dann frazier wrote: > > On Mon, Nov 26, 2018 at 06:43:00PM +, Salil Mehta wrote: > > > From: Peng Li > > > > > > Port 0/1 of HiP08 supports 10G and 25G. This patch

Re: [PATCH net-next] net: hns3: Config NIC port speed same as that of optical module

On Mon, Nov 26, 2018 at 06:43:00PM +, Salil Mehta wrote: > From: Peng Li > > Port 0/1 of HiP08 supports 10G and 25G. This patch adds a > change to configure NIC port speed same as that of optical > module(SFP/QFSP). Driver gets the optical module speed and > sets NIC port speed accordingly.

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

On Sat, Jul 14, 2018 at 5:21 AM dann frazier wrote: > > On Thu, Jul 12, 2018 at 5:08 PM Theodore Y. Ts'o wrote: > > > > > > > > Review console log and on each run I have filesystem rebuild. The problem > > > is that mke2fs I am using is 1.44.3-rc2. I am no

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

On Sat, Jul 14, 2018 at 5:21 AM dann frazier wrote: > > On Thu, Jul 12, 2018 at 5:08 PM Theodore Y. Ts'o wrote: > > > > > > > > Review console log and on each run I have filesystem rebuild. The problem > > > is that mke2fs I am using is 1.44.3-rc2. I am no

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

ck bitmap fix as well, and still no problems, so: Tested-by: dann frazier > commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef > Author: Theodore Ts'o > Date: Thu Jul 12 19:08:05 2018 -0400 > > ext4: check for allocation block validity with block group locked > &

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

ck bitmap fix as well, and still no problems, so: Tested-by: dann frazier > commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef > Author: Theodore Ts'o > Date: Thu Jul 12 19:08:05 2018 -0400 > > ext4: check for allocation block validity with block group locked > &

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

On Tue, Jul 10, 2018 at 10:51:43AM -0600, dann frazier wrote: > On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote: > > On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote: > > > Hi, > > > We're seeing a regression triggered by the stress-ng[*] &

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

On Tue, Jul 10, 2018 at 10:51:43AM -0600, dann frazier wrote: > On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote: > > On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote: > > > Hi, > > > We're seeing a regression triggered by the stress-ng[*] &

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote: > On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote: > > Hi, > > We're seeing a regression triggered by the stress-ng[*] "chdir" test > > that I've bisected to: > > > > 044e

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote: > On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote: > > Hi, > > We're seeing a regression triggered by the stress-ng[*] "chdir" test > > that I've bisected to: > > > > 044e

[Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

Hi, We're seeing a regression triggered by the stress-ng[*] "chdir" test that I've bisected to: 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps So far we've only seen failures on servers based on HiSilicon's family of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these

[Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

Hi, We're seeing a regression triggered by the stress-ng[*] "chdir" test that I've bisected to: 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps So far we've only seen failures on servers based on HiSilicon's family of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these

[PATCH] net: hns: Avoid action name truncation

enahisic2i0-tx /proc/interrupts | sed 's/.* //' enahisic2i0-tx0 enahisic2i0-tx1 enahisic2i0-tx2 [...] enahisic2i0-tx8 enahisic2i0-tx9 enahisic2i0-tx10 enahisic2i0-tx11 enahisic2i0-tx12 enahisic2i0-tx13 enahisic2i0-tx14 enahisic2i0-tx15 Signed-off-by: dann frazier <dann.f

[PATCH] net: hns: Avoid action name truncation

enahisic2i0-tx /proc/interrupts | sed 's/.* //' enahisic2i0-tx0 enahisic2i0-tx1 enahisic2i0-tx2 [...] enahisic2i0-tx8 enahisic2i0-tx9 enahisic2i0-tx10 enahisic2i0-tx11 enahisic2i0-tx12 enahisic2i0-tx13 enahisic2i0-tx14 enahisic2i0-tx15 Signed-off-by: dann frazier --- drivers/net

Re: [PATCH 1/4] i2c: xlp9xx: return ENXIO on slave address NACK

: Tested-by: dann frazier <dann.fraz...@canonical.com> -dann > On 01/18/2018 11:09 AM, George Cherian wrote: >> >> From: Dmitry Bazhenov <dmitry.bazhe...@auriga.com> >> >> Fix the driver violation of the common practice to return >> ENXIO error on a sl

Re: [PATCH 1/4] i2c: xlp9xx: return ENXIO on slave address NACK

On Tue, Jan 30, 2018 at 7:28 AM, George Cherian wrote: > Gentle Ping on this series. I've been using these on a few Cavium Sabre boards, which previously had an unusable system interface (/dev/ipmi) due to timeouts or just enumerations failures. So, fwiw: Tested-by: dann frazier -d

Re: [PATCH v14 0/9] LPC: legacy ISA I/O support

rs/pci/pci.c | 95 +-- > include/asm-generic/io.h | 4 +- > include/linux/logic_pio.h | 131 + > include/linux/pci.h| 3 +- > lib/Kconfig| 15 + > lib/Makefile | 2 + > lib/logic_pio.c| 285 + > 15 files changed, 1250 insertions(+), 98 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt > create mode 100644 drivers/bus/hisi_lpc.c > create mode 100644 include/linux/logic_pio.h > create mode 100644 lib/logic_pio.c Tested this version on a D05 board, no problems. So, for the series: Tested-by: dann frazier <dann.fraz...@canonical.com>

Re: [PATCH v14 0/9] LPC: legacy ISA I/O support

rs/pci/pci.c | 95 +-- > include/asm-generic/io.h | 4 +- > include/linux/logic_pio.h | 131 + > include/linux/pci.h| 3 +- > lib/Kconfig| 15 + > lib/Makefile | 2 + > lib/logic_pio.c| 285 + > 15 files changed, 1250 insertions(+), 98 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt > create mode 100644 drivers/bus/hisi_lpc.c > create mode 100644 include/linux/logic_pio.h > create mode 100644 lib/logic_pio.c Tested this version on a D05 board, no problems. So, for the series: Tested-by: dann frazier

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

On Wed, Feb 14, 2018 at 8:42 AM, John Garry <john.ga...@huawei.com> wrote: > On 13/02/2018 22:57, dann frazier wrote: >> >> On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote: >>> >>> From: Zhichang Yuan <yuanzhich...@hisilicon.com> >&g

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

On Wed, Feb 14, 2018 at 8:42 AM, John Garry wrote: > On 13/02/2018 22:57, dann frazier wrote: >> >> On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote: >>> >>> From: Zhichang Yuan >>> >>> After introducing the new generic I/O space

Re: [PATCH v13 1/9] LIB: Introduce a generic PIO mapping method

On Wed, Feb 14, 2018 at 01:45:25AM +0800, John Garry wrote: > From: Zhichang Yuan > > In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and > pci_pio_to_address()"), a new I/O space management was supported. With > that driver, the I/O ranges configured for

Re: [PATCH v13 1/9] LIB: Introduce a generic PIO mapping method

On Wed, Feb 14, 2018 at 01:45:25AM +0800, John Garry wrote: > From: Zhichang Yuan > > In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and > pci_pio_to_address()"), a new I/O space management was supported. With > that driver, the I/O ranges configured for PCI/PCIe hosts on some >

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote: > From: Zhichang Yuan > > After introducing the new generic I/O space management in logic pio, the > original PCI MMIO relevant helpers need to be updated based on the new > interfaces. > This patch adapts

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote: > From: Zhichang Yuan > > After introducing the new generic I/O space management in logic pio, the > original PCI MMIO relevant helpers need to be updated based on the new > interfaces. > This patch adapts the corresponding code to

Re: [PATCH v12 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

On Wed, Jan 24, 2018 at 12:36:22AM +0800, John Garry wrote: > From: Zhichang Yuan > > The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in > I/O port addresses. This patch implements the LPC host controller driver > which perform the I/O

Re: [PATCH v12 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

On Wed, Jan 24, 2018 at 12:36:22AM +0800, John Garry wrote: > From: Zhichang Yuan > > The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in > I/O port addresses. This patch implements the LPC host controller driver > which perform the I/O operations on the underlying

Re: [PATCH v12 0/9] LPC: legacy ISA I/O support

l be redirected to the > corresponding device-specific I/O hooks to perform the I/O accesses. > > Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals > can > be supported without any changes on the existing ipmi-si driver. > > The whole patchset has

Re: [PATCH v12 0/9] LPC: legacy ISA I/O support

corresponding device-specific I/O hooks to perform the I/O accesses. > > Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals > can > be supported without any changes on the existing ipmi-si driver. > > The whole patchset has been tested on Hip07 D05 board

Re: [PATCH v10 0/9] LPC: legacy ISA I/O support

p07 SoC. fwiw, I tested this on one of our D05 boards and verified that the IPMI SI worked fine. Tested-by: dann frazier <dann.fraz...@canonical.com>

Re: [PATCH v10 0/9] LPC: legacy ISA I/O support

MI SI worked fine. Tested-by: dann frazier

Re: [PATCH v10 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

On Fri, Oct 27, 2017 at 05:11:24PM +0100, Gabriele Paoloni wrote: > From: "zhichang.yuan" > > The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in > I/O port addresses. This patch implements the LPC host controller driver > which perform the I/O

Re: [PATCH v10 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

On Fri, Oct 27, 2017 at 05:11:24PM +0100, Gabriele Paoloni wrote: > From: "zhichang.yuan" > > The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in > I/O port addresses. This patch implements the LPC host controller driver > which perform the I/O operations on the

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

On Mon, Oct 23, 2017 at 3:08 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Mon, 2017-10-23 at 09:41 -0600, dann frazier wrote: >> (gdb) list *(sg_io+0x120) >> 0x084e71a8 is in sg_io (./include/linux/uaccess.h:113). >> 108 static inline unsigned lo

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

On Mon, Oct 23, 2017 at 3:08 PM, Bart Van Assche wrote: > On Mon, 2017-10-23 at 09:41 -0600, dann frazier wrote: >> (gdb) list *(sg_io+0x120) >> 0x084e71a8 is in sg_io (./include/linux/uaccess.h:113). >> 108 static inline unsigned long >> 109 _copy_fro

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

On Fri, Oct 20, 2017 at 11:30:55PM +, Bart Van Assche wrote: > On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote: > > hey, > > I'm seeing a regression when executing 'dmraid -r -c' in an arm64 > > QEMU guest, which I've bisected to the following commit: > >

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

On Fri, Oct 20, 2017 at 11:30:55PM +, Bart Van Assche wrote: > On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote: > > hey, > > I'm seeing a regression when executing 'dmraid -r -c' in an arm64 > > QEMU guest, which I've bisected to the following commit: > >

[bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

hey, I'm seeing a regression when executing 'dmraid -r -c' in an arm64 QEMU guest, which I've bisected to the following commit: ca18d6f7 "block: Make most scsi_req_init() calls implicit" I haven't yet had time to try and debug it yet, but wanted to get the report out there before the

[bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

hey, I'm seeing a regression when executing 'dmraid -r -c' in an arm64 QEMU guest, which I've bisected to the following commit: ca18d6f7 "block: Make most scsi_req_init() calls implicit" I haven't yet had time to try and debug it yet, but wanted to get the report out there before the

Re: [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO

On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan wrote: > On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O > with some special host-local I/O ports known on x86. To access the I/O > peripherals, an indirect-IO mechanism is introduced to

Re: [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO

On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan wrote: > On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O > with some special host-local I/O ports known on x86. To access the I/O > peripherals, an indirect-IO mechanism is introduced to mapped the host-local > I/O to

Re: [PATCH V8 0/7] LPC: legacy ISA I/O support

| 26 + > lib/Makefile | 2 + > lib/logic_pio.c| 413 > 22 files changed, 1758 insertions(+), 102 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt > create mode 100644 drivers/acpi/acpi_indirectio.c > create mode 100644 drivers/bus/hisi_lpc.c > create mode 100644 include/linux/logic_pio.h > create mode 100644 lib/logic_pio.c Booted up on a D05, was able to use the LPC-connected IPMI interface. Tested-by: dann frazier <dann.fraz...@canonical.com>

Re: [PATCH V8 0/7] LPC: legacy ISA I/O support

| 2 + > lib/logic_pio.c| 413 > 22 files changed, 1758 insertions(+), 102 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt > create mode 100644 drivers/acpi/acpi_indirectio.c > create mode 100644 drivers/bus/hisi_lpc.c > create mode 100644 include/linux/logic_pio.h > create mode 100644 lib/logic_pio.c Booted up on a D05, was able to use the LPC-connected IPMI interface. Tested-by: dann frazier

Re: [PATCH V7 2/7] PCI: Apply the new generic I/O management on PCI IO hosts

On Sun, Mar 12, 2017 at 8:42 PM, zhichang.yuan wrote: > After introducing the new generic I/O space management(LIBIO), the original > PCI > MMIO relevant helpers need to be updated based on the new interfaces defined > in > LIBIO. > This patch adapts the

Re: [PATCH V7 2/7] PCI: Apply the new generic I/O management on PCI IO hosts

On Sun, Mar 12, 2017 at 8:42 PM, zhichang.yuan wrote: > After introducing the new generic I/O space management(LIBIO), the original > PCI > MMIO relevant helpers need to be updated based on the new interfaces defined > in > LIBIO. > This patch adapts the corresponding code to match the changes

Re: [PATCH v2 06/18] arm64: arch_timer: Add infrastructure for multiple erratum detection methods

On Mon, Mar 20, 2017 at 11:48 AM, Marc Zyngier wrote: > We're currently stuck with DT when it comes to handling errata, which > is pretty restrictive. In order to make things more flexible, let's > introduce an infrastructure that could support alternative discovery >

Re: [PATCH v2 06/18] arm64: arch_timer: Add infrastructure for multiple erratum detection methods

On Mon, Mar 20, 2017 at 11:48 AM, Marc Zyngier wrote: > We're currently stuck with DT when it comes to handling errata, which > is pretty restrictive. In order to make things more flexible, let's > introduce an infrastructure that could support alternative discovery > methods. No change in

Re: [PATCH 00/17] clocksource/arch_timer: Errara workaround infrastructure rework

Enabling global workaround for HiSilicon erratum 161010101 [0.00] arm_arch_timer: CPU0: Trapping CNTVCT access [0.00] arm_arch_timer: Architected cp15 timer(s) running at 50.00MHz (phys). [0.266571] arm_arch_timer: CPU1: Trapping CNTVCT access [0.270108] arm_arch_timer: CPU2: Trapping CNTVCT access [...] Tested-by: dann frazier <dann.fraz...@canonical.com> -dann

Re: [PATCH 00/17] clocksource/arch_timer: Errara workaround infrastructure rework

Silicon erratum 161010101 [0.00] arm_arch_timer: CPU0: Trapping CNTVCT access [0.00] arm_arch_timer: Architected cp15 timer(s) running at 50.00MHz (phys). [0.266571] arm_arch_timer: CPU1: Trapping CNTVCT access [0.270108] arm_arch_timer: CPU2: Trapping CNTVCT access [...] Tested-by: dann frazier -dann

[PATCH] arm64: Disallow combination of ARCH_XGENE and 16K page size

16K page size is an optional feature of the architecture, and is not supported by the X-Gene SoC family. Signed-off-by: dann frazier --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 21074f6

[PATCH] arm64: Disallow combination of ARCH_XGENE and 16K page size

16K page size is an optional feature of the architecture, and is not supported by the X-Gene SoC family. Signed-off-by: dann frazier <dann.fraz...@canonical.com> --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

On Tue, Jun 9, 2015 at 9:31 AM, Dann Frazier wrote: > On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen wrote: >> Hi Dann, >> >> On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier >> wrote: >>> On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen wrote: >>>

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

On Tue, Jun 9, 2015 at 9:31 AM, Dann Frazier dann.fraz...@canonical.com wrote: On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen ttngu...@apm.com wrote: Hi Dann, On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier dann.fraz...@canonical.com wrote: On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu

Re: [PATCH 1/2 RESEND] power: reset: Add syscon reboot device node for APM X-Gene platform

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen wrote: > This patch adds syscon reboot device node to support reboot feature on APM > X-Gene platform Tested-by: dann frazier > Signed-off-by: Feng Kan > Signed-off-by: Tai Nguyen > --- > arch/arm64/boot/dts/apm/apm

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen wrote: > Hi Dann, > > On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier > wrote: >> On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen wrote: >>> This patch adds syscon poweroff device node to support poweroff feature >>

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen ttngu...@apm.com wrote: Hi Dann, On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier dann.fraz...@canonical.com wrote: On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote: This patch adds syscon poweroff device node to support poweroff

Re: [PATCH 1/2 RESEND] power: reset: Add syscon reboot device node for APM X-Gene platform

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote: This patch adds syscon reboot device node to support reboot feature on APM X-Gene platform Tested-by: dann frazier dann.fraz...@canonical.com Signed-off-by: Feng Kan f...@apm.com Signed-off-by: Tai Nguyen ttngu...@apm.com

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen wrote: > This patch adds syscon poweroff device node to support poweroff feature > on APM X-Gene Mustang platform hey Tai, The reboot changes work just fine for me, but poweroff does not: [ OK ] Reached target Final Step. Starting

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote: This patch adds syscon poweroff device node to support poweroff feature on APM X-Gene Mustang platform hey Tai, The reboot changes work just fine for me, but poweroff does not: [ OK ] Reached target Final Step.

[PATCH] tools: testing: selftests: mq_perf_tests: Fix infinite loop on ARM

We can't use a char type to check for a negative return value since char isn't guaranteed to be signed. Indeed, the char type tends to be unsigned on ARM. Signed-off-by: dann frazier --- tools/testing/selftests/mqueue/mq_perf_tests.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

[PATCH] tools: testing: selftests: mq_perf_tests: Fix infinite loop on ARM

We can't use a char type to check for a negative return value since char isn't guaranteed to be signed. Indeed, the char type tends to be unsigned on ARM. Signed-off-by: dann frazier dann.fraz...@canonical.com --- tools/testing/selftests/mqueue/mq_perf_tests.c | 3 +-- 1 file changed, 1

Re: [PATCH v8 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.

On Fri, Jun 20, 2014 at 5:18 PM, Iyappan Subramanian wrote: > This patch adds network driver for APM X-Gene SoC ethernet. > > Signed-off-by: Iyappan Subramanian > Signed-off-by: Ravi Patel > Signed-off-by: Keyur Chudgar > --- > drivers/net/ethernet/Kconfig | 1 + >

Re: [PATCH v8 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.

On Fri, Jun 20, 2014 at 5:18 PM, Iyappan Subramanian isubraman...@apm.com wrote: This patch adds network driver for APM X-Gene SoC ethernet. Signed-off-by: Iyappan Subramanian isubraman...@apm.com Signed-off-by: Ravi Patel rapa...@apm.com Signed-off-by: Keyur Chudgar kchud...@apm.com ---

lustre virtual block device doesn't build w/ CONFIG_ARM64_64K_PAGES=y

With current git, lustre fails to build with CONFIG_ARM64_64K_PAGES=y and CONFIG_LUSTRE_LLITE_LLOOP=m: make -f scripts/Makefile.build obj=drivers/staging/lustre/lustre/llite gcc -Wp,-MD,drivers/staging/lustre/lustre/llite/.lloop.o.d -nostdinc -isystem

lustre virtual block device doesn't build w/ CONFIG_ARM64_64K_PAGES=y

With current git, lustre fails to build with CONFIG_ARM64_64K_PAGES=y and CONFIG_LUSTRE_LLITE_LLOOP=m: make -f scripts/Makefile.build obj=drivers/staging/lustre/lustre/llite gcc -Wp,-MD,drivers/staging/lustre/lustre/llite/.lloop.o.d -nostdinc -isystem

Re: [PATCH v2] serial: uart: add hw flow control support configuration

On Wed, Jun 11, 2014 at 2:53 PM, Murali Karicheri wrote: > On 5/28/2014 4:04 PM, Dann Frazier wrote: >> >> On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri >> wrote: >>> >>> 8250 uart driver currently supports only software assisted hw flow >>>

Re: [PATCH v2] serial: uart: add hw flow control support configuration

On Wed, Jun 11, 2014 at 2:53 PM, Murali Karicheri m-kariche...@ti.com wrote: On 5/28/2014 4:04 PM, Dann Frazier wrote: On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri m-kariche...@ti.com wrote: 8250 uart driver currently supports only software assisted hw flow control. The software

Re: [PATCH v2] serial: uart: add hw flow control support configuration

.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> UPF_HARDWARE_FLOW = 1 << 21 >>> if 0xB920 & UPF_HARDWARE_FLOW: ... print "OK" ... OK Hope that's a reasonable test case. Test fai

Re: [PATCH v2] serial: uart: add hw flow control support configuration

, copyright, credits or license for more information. UPF_HARDWARE_FLOW = 1 21 if 0xB920 UPF_HARDWARE_FLOW: ... print OK ... OK Hope that's a reasonable test case. Test fails when booted w/o has-hw-flow-control attribute. Tested-by: dann frazier dann.fraz...@canonical.com Signed-off

Re: [RFC PATCH V3 0/4] APM X-Gene PCIe controller

On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar wrote: > This patch adds support for AppliedMicro X-Gene PCIe host controller. The > driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint > cards. > > X-Gene PCIe controller driver has depedency on the pcie arch support for >

Re: [RFC PATCH V3 0/4] APM X-Gene PCIe controller

On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar tinam...@apm.com wrote: This patch adds support for AppliedMicro X-Gene PCIe host controller. The driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint cards. X-Gene PCIe controller driver has depedency on the pcie arch

Re: PROBLEM: 2.4.36.1 hangs.

Theo or Al > for some advices, as I'm not tempted by merging an uncertain patch when > it comes to filesystems. Looks like a test case may be available: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2d7f2ea9c989853310c7f6e8be52cc090cc8e66b -- dan

Re: PROBLEM: 2.4.36.1 hangs.

-2.6.git;a=commitdiff;h=2d7f2ea9c989853310c7f6e8be52cc090cc8e66b -- dann frazier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

[PATCH] 2.4: [POWERPC] CHRP: Fix possible NULL pointer dereference

of strncmp() if of_get_property() fails. Signed-off-by: dann frazier <[EMAIL PROTECTED]> diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c index 0ffbbd2..28747db 100644 --- a/arch/ppc/platforms/chrp_setup.c +++ b/arch/ppc/platforms/chrp_setup.c @@ -121,7

[PATCH] 2.4: [POWERPC] CHRP: Fix possible NULL pointer dereference

of strncmp() if of_get_property() fails. Signed-off-by: dann frazier [EMAIL PROTECTED] diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c index 0ffbbd2..28747db 100644 --- a/arch/ppc/platforms/chrp_setup.c +++ b/arch/ppc/platforms/chrp_setup.c @@ -121,7 +121,7

[PATCH] 2.4: USB: fix DoS in pwc USB video driver

to close the device. This opens up an opportunity for a DoS attack, blocking the USB subsystem and making khubd's task busy wait in kernel space. This patch shifts freeing resources to close if an opened device is disconnected. Signed-off-by: dann frazier <[EMAIL PROTECTED]> --- d

[PATCH] 2.4: [PPPOE]: memory leak when socket is release()d before PPPIOCGCHAN has been called on it

session IDs for a known AC is a kind of DoS, too, after all - with Juniper ERXes, this is really easy, actually, since they don't ever assign session ids above 8000 ... Signed-off-by: dann frazier <[EMAIL PROTECTED]> --- drivers/net/pppox.c |2 +- 1 files changed, 1 insertions

[PATCH] 2.4: [PPPOE]: memory leak when socket is release()d before PPPIOCGCHAN has been called on it

session IDs for a known AC is a kind of DoS, too, after all - with Juniper ERXes, this is really easy, actually, since they don't ever assign session ids above 8000 ... Signed-off-by: dann frazier [EMAIL PROTECTED] --- drivers/net/pppox.c |2 +- 1 files changed, 1 insertions(+), 1 deletions

[PATCH] 2.4: USB: fix DoS in pwc USB video driver

to close the device. This opens up an opportunity for a DoS attack, blocking the USB subsystem and making khubd's task busy wait in kernel space. This patch shifts freeing resources to close if an opened device is disconnected. Signed-off-by: dann frazier [EMAIL PROTECTED] --- drivers/usb

[PATCH] 2.4: [SCSI] aacraid: Fix security hole

permissions check for ioctls (and indeed other drivers implement unprivileged ioctls). aacraid however allows all sorts of very admin only things to be done so should check. --- drivers/scsi/aacraid/linit.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Signed-off-by: dann frazier

[PATCH] 2.4: [SCSI] aacraid: Fix security hole

permissions check for ioctls (and indeed other drivers implement unprivileged ioctls). aacraid however allows all sorts of very admin only things to be done so should check. --- drivers/scsi/aacraid/linit.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Signed-off-by: dann frazier

Re: [PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

On Thu, Jan 24, 2008 at 03:06:58PM -0600, Eric Sandeen wrote: > Willy Tarreau wrote: > > Hi Dann, > > > > On Wed, Jan 23, 2008 at 11:12:12PM -0700, dann frazier wrote: > >> This is a 2.4 backport of a linux-2.6 change by Eric Sandeen > >> (commit b

Re: [PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

On Thu, Jan 24, 2008 at 03:06:58PM -0600, Eric Sandeen wrote: Willy Tarreau wrote: Hi Dann, On Wed, Jan 23, 2008 at 11:12:12PM -0700, dann frazier wrote: This is a 2.4 backport of a linux-2.6 change by Eric Sandeen (commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8) CVE-2006-5753

[PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

, I just went ahead & created an EIO function for each individual file & inode op that returns a value. Signed-off-by: dann frazier <[EMAIL PROTECTED]> --- fs/bad_inode.c | 191 +++- 1 files changed, 161 insertions(+), 30 dele

[PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

a signature, I just went ahead created an EIO function for each individual file inode op that returns a value. Signed-off-by: dann frazier [EMAIL PROTECTED] --- fs/bad_inode.c | 191 +++- 1 files changed, 161 insertions(+), 30 deletions(-) diff

Re: old buffer overflow in moxa driver

, but yes - the CAP_SYS_RAWIO check was added in 2.6.16. -- dann frazier | HP Open Source and Linux Organization - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: old buffer overflow in moxa driver

- the CAP_SYS_RAWIO check was added in 2.6.16. -- dann frazier | HP Open Source and Linux Organization - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ

old buffer overflow in moxa driver

contacting the listed maintainer a few months ago but received no response. I've tested that this still applies to and compiles against 2.6.21. Signed-off-by: dann frazier <[EMAIL PROTECTED]> diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c index 7dbaee8..e0d35c2 100644 --- a/drivers/char/

  1   2   >