Project

General

Profile

Actions

Bug #16503

open

cxgbe: ioctls with no consumers

Added by Ryan Zezeski about 2 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

There are various cxgbe ioctls (T4_IOCTL_*) that have no consumers in gate. I also believe there are no out-of-gate consumers of these ioctls, because their consumer is nominally cxgbetool, which we ship as part of gate. My belief is that the original intention was to consume these ioctls via cxgbetool, like they do in FreeBSD. However, Chelsio developed the "Unified Debugger" (cudbg), and instead we added support for that in 11810. I believe its goal is to replace the usage of cxgbetool.

Here is a list of the ioctls we do not consume:

  • T4_IOCTL_PCIGET32
  • T4_IOCTL_PCIPUT32
  • T4_IOCTL_GET32
  • T4_IOCTL_PUT32
  • T4_IOCTL_REGDUMP
  • T4_IOCTL_SGE_CONTEXT
  • T4_IOCTL_GET_MEM
  • T4_IOCTL_GET_TID_TAB (related to offload, which we don't support)
  • T4_IOCTL_GET_MBOX
  • T4_IOCTL_GET_CIM_LA
  • T4_IOCTL_GET_CIM_QCFG
  • T4_IOCTL_GET_CIM_IBQ
  • T4_IOCTL_GET_EDC

The leaves the ioctls we do consume:

  • T4_IOCTL_DEVLOG -- cxgbetool devlog
  • T4_IOCTL_LOAD_FW -- cxgbetool loadfw
  • T4_IOCTL_GET_CUDBG -- cxgbetool cudbg --collect

I arrived at this issue while looking at T4_IOCTL_REGDUMP. It's missing some bug fixes in it's register maps, and requires a new register map for T7 parts (and really, it should just uses the common code for dumping regs). I then fixed the ioctl only to realize I can't even test it. This is when it dawned on me that the usages of cxgbetool has probably been largely supplanted by CUDBG. For example, you can view the registers with cudbg like so:

# cxgbetool cxgbe0 cudbg --collect allregs regs.txt
# cxgbetool cxgbe0 cudbg --view allregs regs.txt

Like regdump, these other ioctls might have incorrect implementations at this point. And I certainly can't fix them or update them for T7 if I have no way to test them. I believe we should do the following:

1. If an ioctl has an equivalent in cudbg, then use that and remove its t4_ioctl.c code.

Actions #1

Updated by Ryan Zezeski about 2 months ago

Whoops, hit enter early.

1. If an ioctl has an equivalent in cudbg, then use that and remove its t4_ioctl.c code.
2. If an ioctl does not have an equivalent cudbg command, then either remove it or hook it up to cxgbetool.

Actions

Also available in: Atom PDF