@@ -107,10 +108,19 @@ struct nvme_ctrl { u8 event_limit; u8 vwc; u32 vs; + u32 sgls; bool subsystem; unsigned long quirks; struct work_struct scan_work; struct work_struct async_event_work; + + /* Fabrics only */ + u16 sqsize; + u32 ioccsz; + u32 iorcsz; + u16 icdoff; + u16 maxcmd; + struct nvmf_ctrl_options *opts; };The pci only stuff goes in 'struct nvme_dev' and embeds 'struct nvme_ctrl', but fabrics gets to use nvme_ctrl directly? If we need transport specifics for anything, like you have during nvme_init_identify, I think we should add function callbacks to nvme_ctrl_ops to set up those specifics, then we don't need 'is_fabrics' checks.
That's where we started off from :) But we got to a point where it started getting convoluted for generic nvme optional features which are mandatory for fabrics (like keep-alive support) that are detected in different forms (controller identify and fabric admin connect). Anyway we thought it'd be cleaner to have it directly in nvme_ctrl and centralize their assignments in a single location. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
