diff mbox series

[net-next] ptp_ocp: add force_irq to xilinx_spi configuration

Message ID 20230306155726.4035925-1-vadfed@meta.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series [net-next] ptp_ocp: add force_irq to xilinx_spi configuration | expand

Checks

Context Check Description
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit fail Errors and warnings before: 0 this patch: 7
netdev/cc_maintainers warning 1 maintainers not CCed: vadfed@fb.com
netdev/build_clang fail Errors and warnings before: 0 this patch: 7
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn fail Errors and warnings before: 0 this patch: 7
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 7 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Vadim Fedorenko March 6, 2023, 3:57 p.m. UTC
Flashing firmware via devlink flash was failing on PTP OCP devices
because it is using Quad SPI mode, but the driver was not properly
behaving. With force_irq flag landed it now can be fixed.

Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
---
 drivers/ptp/ptp_ocp.c | 1 +
 1 file changed, 1 insertion(+)

Comments

kernel test robot March 6, 2023, 6:17 p.m. UTC | #1
Hi Vadim,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:    https://github.com/intel-lab-lkp/linux/commits/Vadim-Fedorenko/ptp_ocp-add-force_irq-to-xilinx_spi-configuration/20230306-235901
patch link:    https://lore.kernel.org/r/20230306155726.4035925-1-vadfed%40meta.com
patch subject: [net-next] ptp_ocp: add force_irq to xilinx_spi configuration
config: ia64-allyesconfig (https://download.01.org/0day-ci/archive/20230307/202303070211.1hVqbsqg-lkp@intel.com/config)
compiler: ia64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/a30de1354a643bbb9f8e8174332d00d78e74c520
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Vadim-Fedorenko/ptp_ocp-add-force_irq-to-xilinx_spi-configuration/20230306-235901
        git checkout a30de1354a643bbb9f8e8174332d00d78e74c520
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=ia64 olddefconfig
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303070211.1hVqbsqg-lkp@intel.com/

All warnings (new ones prefixed by >>):

   drivers/ptp/ptp_ocp.c:665:34: error: 'struct xspi_platform_data' has no member named 'force_irq'
     665 |                                 .force_irq = true,
         |                                  ^~~~~~~~~
>> drivers/ptp/ptp_ocp.c:665:46: warning: excess elements in struct initializer
     665 |                                 .force_irq = true,
         |                                              ^~~~
   drivers/ptp/ptp_ocp.c:665:46: note: (near initialization for '(anonymous)')


vim +665 drivers/ptp/ptp_ocp.c

   423	
   424	#define OCP_RES_LOCATION(member) \
   425		.name = #member, .bp_offset = offsetof(struct ptp_ocp, member)
   426	
   427	#define OCP_MEM_RESOURCE(member) \
   428		OCP_RES_LOCATION(member), .setup = ptp_ocp_register_mem
   429	
   430	#define OCP_SERIAL_RESOURCE(member) \
   431		OCP_RES_LOCATION(member), .setup = ptp_ocp_register_serial
   432	
   433	#define OCP_I2C_RESOURCE(member) \
   434		OCP_RES_LOCATION(member), .setup = ptp_ocp_register_i2c
   435	
   436	#define OCP_SPI_RESOURCE(member) \
   437		OCP_RES_LOCATION(member), .setup = ptp_ocp_register_spi
   438	
   439	#define OCP_EXT_RESOURCE(member) \
   440		OCP_RES_LOCATION(member), .setup = ptp_ocp_register_ext
   441	
   442	/* This is the MSI vector mapping used.
   443	 * 0: PPS (TS5)
   444	 * 1: TS0
   445	 * 2: TS1
   446	 * 3: GNSS1
   447	 * 4: GNSS2
   448	 * 5: MAC
   449	 * 6: TS2
   450	 * 7: I2C controller
   451	 * 8: HWICAP (notused)
   452	 * 9: SPI Flash
   453	 * 10: NMEA
   454	 * 11: Signal Generator 1
   455	 * 12: Signal Generator 2
   456	 * 13: Signal Generator 3
   457	 * 14: Signal Generator 4
   458	 * 15: TS3
   459	 * 16: TS4
   460	 --
   461	 * 8: Orolia TS1
   462	 * 10: Orolia TS2
   463	 * 11: Orolia TS0 (GNSS)
   464	 * 12: Orolia PPS
   465	 * 14: Orolia TS3
   466	 * 15: Orolia TS4
   467	 */
   468	
   469	static struct ocp_resource ocp_fb_resource[] = {
   470		{
   471			OCP_MEM_RESOURCE(reg),
   472			.offset = 0x01000000, .size = 0x10000,
   473		},
   474		{
   475			OCP_EXT_RESOURCE(ts0),
   476			.offset = 0x01010000, .size = 0x10000, .irq_vec = 1,
   477			.extra = &(struct ptp_ocp_ext_info) {
   478				.index = 0,
   479				.irq_fcn = ptp_ocp_ts_irq,
   480				.enable = ptp_ocp_ts_enable,
   481			},
   482		},
   483		{
   484			OCP_EXT_RESOURCE(ts1),
   485			.offset = 0x01020000, .size = 0x10000, .irq_vec = 2,
   486			.extra = &(struct ptp_ocp_ext_info) {
   487				.index = 1,
   488				.irq_fcn = ptp_ocp_ts_irq,
   489				.enable = ptp_ocp_ts_enable,
   490			},
   491		},
   492		{
   493			OCP_EXT_RESOURCE(ts2),
   494			.offset = 0x01060000, .size = 0x10000, .irq_vec = 6,
   495			.extra = &(struct ptp_ocp_ext_info) {
   496				.index = 2,
   497				.irq_fcn = ptp_ocp_ts_irq,
   498				.enable = ptp_ocp_ts_enable,
   499			},
   500		},
   501		{
   502			OCP_EXT_RESOURCE(ts3),
   503			.offset = 0x01110000, .size = 0x10000, .irq_vec = 15,
   504			.extra = &(struct ptp_ocp_ext_info) {
   505				.index = 3,
   506				.irq_fcn = ptp_ocp_ts_irq,
   507				.enable = ptp_ocp_ts_enable,
   508			},
   509		},
   510		{
   511			OCP_EXT_RESOURCE(ts4),
   512			.offset = 0x01120000, .size = 0x10000, .irq_vec = 16,
   513			.extra = &(struct ptp_ocp_ext_info) {
   514				.index = 4,
   515				.irq_fcn = ptp_ocp_ts_irq,
   516				.enable = ptp_ocp_ts_enable,
   517			},
   518		},
   519		/* Timestamp for PHC and/or PPS generator */
   520		{
   521			OCP_EXT_RESOURCE(pps),
   522			.offset = 0x010C0000, .size = 0x10000, .irq_vec = 0,
   523			.extra = &(struct ptp_ocp_ext_info) {
   524				.index = 5,
   525				.irq_fcn = ptp_ocp_ts_irq,
   526				.enable = ptp_ocp_ts_enable,
   527			},
   528		},
   529		{
   530			OCP_EXT_RESOURCE(signal_out[0]),
   531			.offset = 0x010D0000, .size = 0x10000, .irq_vec = 11,
   532			.extra = &(struct ptp_ocp_ext_info) {
   533				.index = 1,
   534				.irq_fcn = ptp_ocp_signal_irq,
   535				.enable = ptp_ocp_signal_enable,
   536			},
   537		},
   538		{
   539			OCP_EXT_RESOURCE(signal_out[1]),
   540			.offset = 0x010E0000, .size = 0x10000, .irq_vec = 12,
   541			.extra = &(struct ptp_ocp_ext_info) {
   542				.index = 2,
   543				.irq_fcn = ptp_ocp_signal_irq,
   544				.enable = ptp_ocp_signal_enable,
   545			},
   546		},
   547		{
   548			OCP_EXT_RESOURCE(signal_out[2]),
   549			.offset = 0x010F0000, .size = 0x10000, .irq_vec = 13,
   550			.extra = &(struct ptp_ocp_ext_info) {
   551				.index = 3,
   552				.irq_fcn = ptp_ocp_signal_irq,
   553				.enable = ptp_ocp_signal_enable,
   554			},
   555		},
   556		{
   557			OCP_EXT_RESOURCE(signal_out[3]),
   558			.offset = 0x01100000, .size = 0x10000, .irq_vec = 14,
   559			.extra = &(struct ptp_ocp_ext_info) {
   560				.index = 4,
   561				.irq_fcn = ptp_ocp_signal_irq,
   562				.enable = ptp_ocp_signal_enable,
   563			},
   564		},
   565		{
   566			OCP_MEM_RESOURCE(pps_to_ext),
   567			.offset = 0x01030000, .size = 0x10000,
   568		},
   569		{
   570			OCP_MEM_RESOURCE(pps_to_clk),
   571			.offset = 0x01040000, .size = 0x10000,
   572		},
   573		{
   574			OCP_MEM_RESOURCE(tod),
   575			.offset = 0x01050000, .size = 0x10000,
   576		},
   577		{
   578			OCP_MEM_RESOURCE(irig_in),
   579			.offset = 0x01070000, .size = 0x10000,
   580		},
   581		{
   582			OCP_MEM_RESOURCE(irig_out),
   583			.offset = 0x01080000, .size = 0x10000,
   584		},
   585		{
   586			OCP_MEM_RESOURCE(dcf_in),
   587			.offset = 0x01090000, .size = 0x10000,
   588		},
   589		{
   590			OCP_MEM_RESOURCE(dcf_out),
   591			.offset = 0x010A0000, .size = 0x10000,
   592		},
   593		{
   594			OCP_MEM_RESOURCE(nmea_out),
   595			.offset = 0x010B0000, .size = 0x10000,
   596		},
   597		{
   598			OCP_MEM_RESOURCE(image),
   599			.offset = 0x00020000, .size = 0x1000,
   600		},
   601		{
   602			OCP_MEM_RESOURCE(pps_select),
   603			.offset = 0x00130000, .size = 0x1000,
   604		},
   605		{
   606			OCP_MEM_RESOURCE(sma_map1),
   607			.offset = 0x00140000, .size = 0x1000,
   608		},
   609		{
   610			OCP_MEM_RESOURCE(sma_map2),
   611			.offset = 0x00220000, .size = 0x1000,
   612		},
   613		{
   614			OCP_I2C_RESOURCE(i2c_ctrl),
   615			.offset = 0x00150000, .size = 0x10000, .irq_vec = 7,
   616			.extra = &(struct ptp_ocp_i2c_info) {
   617				.name = "xiic-i2c",
   618				.fixed_rate = 50000000,
   619				.data_size = sizeof(struct xiic_i2c_platform_data),
   620				.data = &(struct xiic_i2c_platform_data) {
   621					.num_devices = 2,
   622					.devices = (struct i2c_board_info[]) {
   623						{ I2C_BOARD_INFO("24c02", 0x50) },
   624						{ I2C_BOARD_INFO("24mac402", 0x58),
   625						  .platform_data = "mac" },
   626					},
   627				},
   628			},
   629		},
   630		{
   631			OCP_SERIAL_RESOURCE(gnss_port),
   632			.offset = 0x00160000 + 0x1000, .irq_vec = 3,
   633			.extra = &(struct ptp_ocp_serial_port) {
   634				.baud = 115200,
   635			},
   636		},
   637		{
   638			OCP_SERIAL_RESOURCE(gnss2_port),
   639			.offset = 0x00170000 + 0x1000, .irq_vec = 4,
   640			.extra = &(struct ptp_ocp_serial_port) {
   641				.baud = 115200,
   642			},
   643		},
   644		{
   645			OCP_SERIAL_RESOURCE(mac_port),
   646			.offset = 0x00180000 + 0x1000, .irq_vec = 5,
   647			.extra = &(struct ptp_ocp_serial_port) {
   648				.baud = 57600,
   649			},
   650		},
   651		{
   652			OCP_SERIAL_RESOURCE(nmea_port),
   653			.offset = 0x00190000 + 0x1000, .irq_vec = 10,
   654		},
   655		{
   656			OCP_SPI_RESOURCE(spi_flash),
   657			.offset = 0x00310000, .size = 0x10000, .irq_vec = 9,
   658			.extra = &(struct ptp_ocp_flash_info) {
   659				.name = "xilinx_spi", .pci_offset = 0,
   660				.data_size = sizeof(struct xspi_platform_data),
   661				.data = &(struct xspi_platform_data) {
   662					.num_chipselect = 1,
   663					.bits_per_word = 8,
   664					.num_devices = 1,
 > 665					.force_irq = true,
   666					.devices = &(struct spi_board_info) {
   667						.modalias = "spi-nor",
   668					},
   669				},
   670			},
   671		},
   672		{
   673			OCP_MEM_RESOURCE(freq_in[0]),
   674			.offset = 0x01200000, .size = 0x10000,
   675		},
   676		{
   677			OCP_MEM_RESOURCE(freq_in[1]),
   678			.offset = 0x01210000, .size = 0x10000,
   679		},
   680		{
   681			OCP_MEM_RESOURCE(freq_in[2]),
   682			.offset = 0x01220000, .size = 0x10000,
   683		},
   684		{
   685			OCP_MEM_RESOURCE(freq_in[3]),
   686			.offset = 0x01230000, .size = 0x10000,
   687		},
   688		{
   689			.setup = ptp_ocp_fb_board_init,
   690		},
   691		{ }
   692	};
   693
Jakub Kicinski March 6, 2023, 8:49 p.m. UTC | #2
On Mon, 6 Mar 2023 07:57:26 -0800 Vadim Fedorenko wrote:
> Flashing firmware via devlink flash was failing on PTP OCP devices
> because it is using Quad SPI mode, but the driver was not properly
> behaving. With force_irq flag landed it now can be fixed.
> 
> Signed-off-by: Vadim Fedorenko <vadfed@meta.com>

Give it until Friday, the patch needs to be in the networking trees
(our PR cadence during the merge window is less regular than outside
it).
Vadim Fedorenko March 6, 2023, 9:10 p.m. UTC | #3
On 06.03.2023 20:49, Jakub Kicinski wrote:
> On Mon, 6 Mar 2023 07:57:26 -0800 Vadim Fedorenko wrote:
>> Flashing firmware via devlink flash was failing on PTP OCP devices
>> because it is using Quad SPI mode, but the driver was not properly
>> behaving. With force_irq flag landed it now can be fixed.
>>
>> Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
> 
> Give it until Friday, the patch needs to be in the networking trees
> (our PR cadence during the merge window is less regular than outside
> it).

Looks like "1dd46599f83a spi: xilinx: add force_irq for QSPI mode" is in net and 
net-next trees already? Or which patch are you talking about?
Jakub Kicinski March 6, 2023, 9:20 p.m. UTC | #4
On Mon, 6 Mar 2023 21:10:40 +0000 Vadim Fedorenko wrote:
> On 06.03.2023 20:49, Jakub Kicinski wrote:
> > On Mon, 6 Mar 2023 07:57:26 -0800 Vadim Fedorenko wrote:  
> >> Flashing firmware via devlink flash was failing on PTP OCP devices
> >> because it is using Quad SPI mode, but the driver was not properly
> >> behaving. With force_irq flag landed it now can be fixed.
> >>
> >> Signed-off-by: Vadim Fedorenko <vadfed@meta.com>  
> > 
> > Give it until Friday, the patch needs to be in the networking trees
> > (our PR cadence during the merge window is less regular than outside
> > it).  
> 
> Looks like "1dd46599f83a spi: xilinx: add force_irq for QSPI mode" is in net and 
> net-next trees already? Or which patch are you talking about?

Hm, you're right. Any idea why both kbuild bot and our own CI think
this doesn't build, then?
Jakub Kicinski March 6, 2023, 9:22 p.m. UTC | #5
On Mon, 6 Mar 2023 13:20:13 -0800 Jakub Kicinski wrote:
> On Mon, 6 Mar 2023 21:10:40 +0000 Vadim Fedorenko wrote:
> > On 06.03.2023 20:49, Jakub Kicinski wrote:  
> > > Give it until Friday, the patch needs to be in the networking trees
> > > (our PR cadence during the merge window is less regular than outside
> > > it).    
> > 
> > Looks like "1dd46599f83a spi: xilinx: add force_irq for QSPI mode" is in net and 
> > net-next trees already? Or which patch are you talking about?  
> 
> Hm, you're right. Any idea why both kbuild bot and our own CI think
> this doesn't build, then?

Probably because they both use master :S

kernel test robot folks, could you please switch from master to main
as the base for networking patches?
Vadim Fedorenko March 6, 2023, 10:47 p.m. UTC | #6
On 06.03.2023 21:22, Jakub Kicinski wrote:
> On Mon, 6 Mar 2023 13:20:13 -0800 Jakub Kicinski wrote:
>> On Mon, 6 Mar 2023 21:10:40 +0000 Vadim Fedorenko wrote:
>>> On 06.03.2023 20:49, Jakub Kicinski wrote:
>>>> Give it until Friday, the patch needs to be in the networking trees
>>>> (our PR cadence during the merge window is less regular than outside
>>>> it).
>>>
>>> Looks like "1dd46599f83a spi: xilinx: add force_irq for QSPI mode" is in net and
>>> net-next trees already? Or which patch are you talking about?
>>
>> Hm, you're right. Any idea why both kbuild bot and our own CI think
>> this doesn't build, then?
> 
> Probably because they both use master :S
> 
> kernel test robot folks, could you please switch from master to main
> as the base for networking patches?

Very interesting side effect of renaming!
Thanks!
Vadim Fedorenko March 8, 2023, 7:01 p.m. UTC | #7
On 06/03/2023 21:22, Jakub Kicinski wrote:
> On Mon, 6 Mar 2023 13:20:13 -0800 Jakub Kicinski wrote:
>> On Mon, 6 Mar 2023 21:10:40 +0000 Vadim Fedorenko wrote:
>>> On 06.03.2023 20:49, Jakub Kicinski wrote:
>>>> Give it until Friday, the patch needs to be in the networking trees
>>>> (our PR cadence during the merge window is less regular than outside
>>>> it).
>>>
>>> Looks like "1dd46599f83a spi: xilinx: add force_irq for QSPI mode" is in net and
>>> net-next trees already? Or which patch are you talking about?
>>
>> Hm, you're right. Any idea why both kbuild bot and our own CI think
>> this doesn't build, then?
> 
> Probably because they both use master :S
> 
> kernel test robot folks, could you please switch from master to main
> as the base for networking patches?

Should I re-send it? It's marked as Deffered and is not going forward...
Jakub Kicinski March 9, 2023, 2:25 a.m. UTC | #8
On Wed, 8 Mar 2023 19:01:22 +0000 Vadim Fedorenko wrote:
> On 06/03/2023 21:22, Jakub Kicinski wrote:
> > On Mon, 6 Mar 2023 13:20:13 -0800 Jakub Kicinski wrote:  
> >> Hm, you're right. Any idea why both kbuild bot and our own CI think
> >> this doesn't build, then?  
> > 
> > Probably because they both use master :S
> > 
> > kernel test robot folks, could you please switch from master to main
> > as the base for networking patches?  
> 
> Should I re-send it? It's marked as Deffered and is not going forward...

Yes, please, not sure why it's Deferred so let's do a resend.
diff mbox series

Patch

diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c
index 4bbaccd543ad..2b63f3487645 100644
--- a/drivers/ptp/ptp_ocp.c
+++ b/drivers/ptp/ptp_ocp.c
@@ -662,6 +662,7 @@  static struct ocp_resource ocp_fb_resource[] = {
 				.num_chipselect = 1,
 				.bits_per_word = 8,
 				.num_devices = 1,
+				.force_irq = true,
 				.devices = &(struct spi_board_info) {
 					.modalias = "spi-nor",
 				},