On 12/03/2020 08:49, Jinpu Wang wrote:
On Wed, Mar 11, 2020 at 11:13 PM Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote:
On 2020-03-11 1:08 p.m., Jinpu Wang wrote:
On Tue, Jan 28, 2020 at 10:43 AM <Deepak.Ukey@xxxxxxxxxxxxx> wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
On 22/01/2020 08:50, Deepak.Ukey@xxxxxxxxxxxxx wrote:
-r--r--r-- 1 root root 4096 Jan 21 12:05 running_disparity_error_count
***
-r--r--r-- 1 root root 4096 Jan 21 12:05 sas_address
lrwxrwxrwx 1 root root 0 Jan 21 11:45 subsystem ->
../../../../../../../class/sas_phy
-r--r--r-- 1 root root 4096 Jan 21 12:05 target_port_protocols
-rw-r--r-- 1 root root 4096 Jan 21 11:45 uevent
Maybe the other stuff provided in the patches are useful, I don't know.
But debugfs seems better for that.
- 0006-pm80xx-sysfs-attribute-for-number-of-phys
- 0007-pm80xx-IOCTL-functionality-to-get-phy-status gets things like Programmed Link Rate, Negotiated Link Rate, PHY Identifier
- 0008-pm80xx-IOCTL-functionality-to-get-phy-error provides other things like Invalid Dword Error Count, Disparity Error Count
- Thanks for addressing it. We can get this info from /sys/class/sas_phy and /sys/class/sas_port so we will drop these above mentioned three patches from the next - patch series.
- 0009-pm80xx-IOCTL-functionality-for-GPIO
- 0013-pm80xx-IOCTL-functionality-for-TWI-device
- For the above patches management utility passes command specific information to driver through IOCTL structure, which used by driver to frame the command and - send to FW. We are using the IOCTL interface for the same. Please let us know your thought.
So I specifically questioned the SGPIO patch and why it would have an IOCTL, as this function is supported in kernel libsas/SAS transport code as an SMP function.
Thank you for your suggestions. We will make use of function supported in libsas.
So basically you only need IOCTL for GPIO and TWI devices, others can
implement via libsas interface or from sysfs directly.
I would like to suggest you do send out other changes without the
IOCTL parts first, and consider again Is it really needed by the user
to control GPIO and TWI, and if there is other way to do it?
Sorry, I don't have a better suggestion!
LSI SAS HBAs (LSI now owned by Broadcom) implement an internal ** SMP
target. It can be seen here:
# ls /dev/bsg
3:0:0:0 3:0:3:0 8:0:0:0 8:0:0:3 end_device-3:1 expander-3:0
3:0:1:0 4:0:0:0 8:0:0:1 8:0:0:4 end_device-3:1:0 expander-3:1
3:0:2:0 7:0:0:0 8:0:0:2 end_device-3:0:1 end_device-3:2 sas_host3
It is the last device node: "sas_host3". How do I know it is a SMP target?
Because this works:
# smp_read_gpio /dev/bsg/sas_host3
Read GPIO register response:
GPIO_CFG[0]:
version: 0
GPIO enable: 1
cfg register count: 2
gp register count: 1
supported drive count: 16
JFYI, that specific command is not implemented for libsas SMP host
handler (see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/libsas/sas_host_smp.c?h=v5.6-rc5#n278),
but the write command should be ok
When you work out what LSI are doing with this, perhaps you could write
an article about it and make it publicly available.
Firmware magic...
It is always a good idea to see how your competitors solve problems :-)
This sounds indeed a better solution, thanks for the info, Doug
@Deepak Ukey can you check if you guys can also do it this way?
Regards,
Jack Wang
.
