Differential D20892 Diff 59571 sys/dev/ntb/ntb_hw/ntb_hw_amd.h

Changeset View

Standalone View

sys/dev/ntb/ntb_hw/ntb_hw_amd.h

Context not available.
	#define NTB_HW_AMD_H	#define NTB_HW_AMD_H

	#define NTB_HW_AMD_VENDOR_ID 0x1022	#define NTB_HW_AMD_VENDOR_ID 0x1022
	#define NTB_HW_AMD_DEVICE_ID 0x145B	#define NTB_HW_AMD_DEVICE_ID1 0x145B
		#define NTB_HW_AMD_DEVICE_ID2 0x148B

	#define NTB_DEF_PEER_CNT 1	#define NTB_DEF_PEER_CNT 1
	#define NTB_DEF_PEER_IDX 0	#define NTB_DEF_PEER_IDX 0
		cemUnsubmitted Not Done Inline Actions It doesn't make a lot of sense to declare a variable (`amd_ntb_hw_info_list`) in a header, since it will be instantiated each time the header is included. I also don't think it makes sense to store this data separately, but referenced, from the `amd_ntb_devs` table below. I would just add the needed PCI VID:DID/description fields to `struct amd_ntb_hw_info` and use that structure for `amd_ntb_devs`. `amd_ntb_devs` is not required to be a `struct pci_device_table`. This table should be `const`. cem: It doesn't make a lot of sense to declare a variable (`amd_ntb_hw_info_list`) in a header…
		rajesh1.kumar_amd.comAuthorUnsubmitted Done Inline Actions Moved the amd_ntb_hw_info_list definition to ntb_hw_amd.c file itself and marked it as static const. Also marked the amd_ntb_devs to be static const. I understand, you mention to remove two different structures (amd_ntb_hw_info -> amd_ntb_hw_info_list) and (pci_device_table -> amd_ntb_devs) and make them as single structure directly with all details. If so, the reason, why I implemented the pci_device_table is to use the PCI_MATCH macro and PCI_PNP_INFO from the pci subsystem. This was one of the suggested changes when this file is submitted for the first time. So I retain those two structures but with some of your suggested changes. If I understand wrongly, please correct me. rajesh1.kumar_amd.com: Moved the amd_ntb_hw_info_list definition to ntb_hw_amd.c file itself and marked it as static…
		cemUnsubmitted Not Done Inline Actions The `PCI_PNP_INFO` macro could still be used on a complete table so long as the `struct pci_device_table` is the first member of each table entry. Yes, it breaks `PCI_MATCH`. I don't think there is any real reason to prefer these matching/pnp macros. cem: The `PCI_PNP_INFO` macro //could// still be used on a complete table so long as the `struct…
		cemUnsubmitted Done Inline Actions I don't think it makes much sense to define these as enums anymore. They're only used once, in the `amd_ntb_hw_info_list` table instantiation. Instead, the numbers can just be placed in the table directly. cem: I don't think it makes much sense to define these as enums anymore. They're only used once, in…
		rajesh1.kumar_amd.comAuthorUnsubmitted Done Inline Actions I believe, you mentioned about AMD_MW_CNT1/2, AMD_BART_START_IDX1/2, AMD_DB_CNT and AMD_SPADS_CNT. If so, they are removed now and the numbers are used directly. rajesh1.kumar_amd.com: I believe, you mentioned about AMD_MW_CNT1/2, AMD_BART_START_IDX1/2, AMD_DB_CNT and…
Context not available.

	enum {	enum {
	/* AMD NTB Capability */	/* AMD NTB Capability */
	AMD_MW_CNT = 3,	AMD_MW_CNT1 = 3,
		AMD_MW_CNT2 = 2,
		AMD_BAR_START_IDX1 = 1,
		AMD_BAR_START_IDX2 = 2,
	AMD_DB_CNT = 16,	AMD_DB_CNT = 16,
	AMD_MSIX_VECTOR_CNT = 24,	AMD_MSIX_VECTOR_CNT = 24,
	AMD_SPADS_CNT = 16,	AMD_SPADS_CNT = 16,
Context not available.
	struct callout hb_timer;	struct callout hb_timer;

	uint8_t mw_count;	uint8_t mw_count;
		uint8_t bar_start_idx;
	uint8_t spad_count;	uint8_t spad_count;
	uint8_t db_count;	uint8_t db_count;
	uint8_t msix_vec_count;	uint8_t msix_vec_count;
Context not available.