2018-03-20 14:58:06 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
/* Copyright (c) 2018, Intel Corporation. */
|
|
|
|
|
|
|
|
#ifndef _ICE_OSDEP_H_
|
|
|
|
#define _ICE_OSDEP_H_
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
ice: remove circular header dependencies on ice.h
Several headers in the ice driver include ice.h even though they are
themselves included by that header. The most notable of these is
ice_common.h, but several other headers also do this.
Such a recursive inclusion is problematic as it forces headers to be
included in a strict order, otherwise compilation errors can result. The
circular inclusions do not trigger an endless loop due to standard
header inclusion guards, however other errors can occur.
For example, ice_flow.h defines ice_rss_hash_cfg, which is used by
ice_sriov.h as part of the definition of ice_vf_hash_ip_ctx.
ice_flow.h includes ice_acl.h, which includes ice_common.h, and which
finally includes ice.h. Since ice.h itself includes ice_sriov.h, this
creates a circular dependency.
The definition in ice_sriov.h requires things from ice_flow.h, but
ice_flow.h itself will lead to trying to load ice_sriov.h as part of its
process for expanding ice.h. The current code avoids this issue by
having an implicit dependency without the include of ice_flow.h.
If we were to fix that so that ice_sriov.h explicitly depends on
ice_flow.h the following pattern would occur:
ice_flow.h -> ice_acl.h -> ice_common.h -> ice.h -> ice_sriov.h
At this point, during the expansion of, the header guard for ice_flow.h
is already set, so when ice_sriov.h attempts to load the ice_flow.h
header it is skipped. Then, we go on to begin including the rest of
ice_sriov.h, including structure definitions which depend on
ice_rss_hash_cfg. This produces a compiler warning because
ice_rss_hash_cfg hasn't yet been included. Remember, we're just at the
start of ice_flow.h!
If the order of headers is incorrect (ice_flow.h is not implicitly
loaded first in all files which include ice_sriov.h) then we get the
same failure.
Removing this recursive inclusion requires fixing a few cases where some
headers depended on the header inclusions from ice.h. In addition, a few
other changes are also required.
Most notably, ice_hw_to_dev is implemented as a macro in ice_osdep.h,
which is the likely reason that ice_common.h includes ice.h at all. This
macro implementation requires the full definition of ice_pf in order to
properly compile.
Fix this by moving it to a function declared in ice_main.c, so that we
do not require all files to depend on the layout of the ice_pf
structure.
Note that this change only fixes circular dependencies, but it does not
fully resolve all implicit dependencies where one header may depend on
the inclusion of another. I tried to fix as many of the implicit
dependencies as I noticed, but fixing them all requires a somewhat
tedious analysis of each header and attempting to compile it separately.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-23 00:26:50 +00:00
|
|
|
#include <linux/ctype.h>
|
|
|
|
#include <linux/delay.h>
|
2018-03-20 14:58:06 +00:00
|
|
|
#include <linux/io.h>
|
ice: remove circular header dependencies on ice.h
Several headers in the ice driver include ice.h even though they are
themselves included by that header. The most notable of these is
ice_common.h, but several other headers also do this.
Such a recursive inclusion is problematic as it forces headers to be
included in a strict order, otherwise compilation errors can result. The
circular inclusions do not trigger an endless loop due to standard
header inclusion guards, however other errors can occur.
For example, ice_flow.h defines ice_rss_hash_cfg, which is used by
ice_sriov.h as part of the definition of ice_vf_hash_ip_ctx.
ice_flow.h includes ice_acl.h, which includes ice_common.h, and which
finally includes ice.h. Since ice.h itself includes ice_sriov.h, this
creates a circular dependency.
The definition in ice_sriov.h requires things from ice_flow.h, but
ice_flow.h itself will lead to trying to load ice_sriov.h as part of its
process for expanding ice.h. The current code avoids this issue by
having an implicit dependency without the include of ice_flow.h.
If we were to fix that so that ice_sriov.h explicitly depends on
ice_flow.h the following pattern would occur:
ice_flow.h -> ice_acl.h -> ice_common.h -> ice.h -> ice_sriov.h
At this point, during the expansion of, the header guard for ice_flow.h
is already set, so when ice_sriov.h attempts to load the ice_flow.h
header it is skipped. Then, we go on to begin including the rest of
ice_sriov.h, including structure definitions which depend on
ice_rss_hash_cfg. This produces a compiler warning because
ice_rss_hash_cfg hasn't yet been included. Remember, we're just at the
start of ice_flow.h!
If the order of headers is incorrect (ice_flow.h is not implicitly
loaded first in all files which include ice_sriov.h) then we get the
same failure.
Removing this recursive inclusion requires fixing a few cases where some
headers depended on the header inclusions from ice.h. In addition, a few
other changes are also required.
Most notably, ice_hw_to_dev is implemented as a macro in ice_osdep.h,
which is the likely reason that ice_common.h includes ice.h at all. This
macro implementation requires the full definition of ice_pf in order to
properly compile.
Fix this by moving it to a function declared in ice_main.c, so that we
do not require all files to depend on the layout of the ice_pf
structure.
Note that this change only fixes circular dependencies, but it does not
fully resolve all implicit dependencies where one header may depend on
the inclusion of another. I tried to fix as many of the implicit
dependencies as I noticed, but fixing them all requires a somewhat
tedious analysis of each header and attempting to compile it separately.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-23 00:26:50 +00:00
|
|
|
#include <linux/bitops.h>
|
|
|
|
#include <linux/ethtool.h>
|
|
|
|
#include <linux/etherdevice.h>
|
|
|
|
#include <linux/if_ether.h>
|
|
|
|
#include <linux/pci_ids.h>
|
2018-03-20 14:58:06 +00:00
|
|
|
#ifndef CONFIG_64BIT
|
|
|
|
#include <linux/io-64-nonatomic-lo-hi.h>
|
|
|
|
#endif
|
2021-12-02 16:38:41 +00:00
|
|
|
#include <net/udp_tunnel.h>
|
2018-03-20 14:58:06 +00:00
|
|
|
|
|
|
|
#define wr32(a, reg, value) writel((value), ((a)->hw_addr + (reg)))
|
|
|
|
#define rd32(a, reg) readl((a)->hw_addr + (reg))
|
|
|
|
#define wr64(a, reg, value) writeq((value), ((a)->hw_addr + (reg)))
|
|
|
|
#define rd64(a, reg) readq((a)->hw_addr + (reg))
|
|
|
|
|
2018-03-20 14:58:07 +00:00
|
|
|
#define ice_flush(a) rd32((a), GLGEN_STAT)
|
2024-02-06 02:29:06 +00:00
|
|
|
#define ICE_M(m, s) ((m ## U) << (s))
|
2018-03-20 14:58:06 +00:00
|
|
|
|
|
|
|
struct ice_dma_mem {
|
|
|
|
void *va;
|
|
|
|
dma_addr_t pa;
|
|
|
|
size_t size;
|
|
|
|
};
|
|
|
|
|
ice: remove circular header dependencies on ice.h
Several headers in the ice driver include ice.h even though they are
themselves included by that header. The most notable of these is
ice_common.h, but several other headers also do this.
Such a recursive inclusion is problematic as it forces headers to be
included in a strict order, otherwise compilation errors can result. The
circular inclusions do not trigger an endless loop due to standard
header inclusion guards, however other errors can occur.
For example, ice_flow.h defines ice_rss_hash_cfg, which is used by
ice_sriov.h as part of the definition of ice_vf_hash_ip_ctx.
ice_flow.h includes ice_acl.h, which includes ice_common.h, and which
finally includes ice.h. Since ice.h itself includes ice_sriov.h, this
creates a circular dependency.
The definition in ice_sriov.h requires things from ice_flow.h, but
ice_flow.h itself will lead to trying to load ice_sriov.h as part of its
process for expanding ice.h. The current code avoids this issue by
having an implicit dependency without the include of ice_flow.h.
If we were to fix that so that ice_sriov.h explicitly depends on
ice_flow.h the following pattern would occur:
ice_flow.h -> ice_acl.h -> ice_common.h -> ice.h -> ice_sriov.h
At this point, during the expansion of, the header guard for ice_flow.h
is already set, so when ice_sriov.h attempts to load the ice_flow.h
header it is skipped. Then, we go on to begin including the rest of
ice_sriov.h, including structure definitions which depend on
ice_rss_hash_cfg. This produces a compiler warning because
ice_rss_hash_cfg hasn't yet been included. Remember, we're just at the
start of ice_flow.h!
If the order of headers is incorrect (ice_flow.h is not implicitly
loaded first in all files which include ice_sriov.h) then we get the
same failure.
Removing this recursive inclusion requires fixing a few cases where some
headers depended on the header inclusions from ice.h. In addition, a few
other changes are also required.
Most notably, ice_hw_to_dev is implemented as a macro in ice_osdep.h,
which is the likely reason that ice_common.h includes ice.h at all. This
macro implementation requires the full definition of ice_pf in order to
properly compile.
Fix this by moving it to a function declared in ice_main.c, so that we
do not require all files to depend on the layout of the ice_pf
structure.
Note that this change only fixes circular dependencies, but it does not
fully resolve all implicit dependencies where one header may depend on
the inclusion of another. I tried to fix as many of the implicit
dependencies as I noticed, but fixing them all requires a somewhat
tedious analysis of each header and attempting to compile it separately.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-23 00:26:50 +00:00
|
|
|
struct ice_hw;
|
|
|
|
struct device *ice_hw_to_dev(struct ice_hw *hw);
|
2018-03-20 14:58:06 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_DYNAMIC_DEBUG
|
|
|
|
#define ice_debug(hw, type, fmt, args...) \
|
|
|
|
dev_dbg(ice_hw_to_dev(hw), fmt, ##args)
|
|
|
|
|
|
|
|
#define ice_debug_array(hw, type, rowsize, groupsize, buf, len) \
|
|
|
|
print_hex_dump_debug(KBUILD_MODNAME " ", \
|
|
|
|
DUMP_PREFIX_OFFSET, rowsize, \
|
|
|
|
groupsize, buf, len, false)
|
|
|
|
#else
|
|
|
|
#define ice_debug(hw, type, fmt, args...) \
|
|
|
|
do { \
|
|
|
|
if ((type) & (hw)->debug_mask) \
|
|
|
|
dev_info(ice_hw_to_dev(hw), fmt, ##args); \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
#ifdef DEBUG
|
|
|
|
#define ice_debug_array(hw, type, rowsize, groupsize, buf, len) \
|
|
|
|
do { \
|
|
|
|
if ((type) & (hw)->debug_mask) \
|
|
|
|
print_hex_dump_debug(KBUILD_MODNAME, \
|
|
|
|
DUMP_PREFIX_OFFSET, \
|
|
|
|
rowsize, groupsize, buf, \
|
|
|
|
len, false); \
|
|
|
|
} while (0)
|
|
|
|
#else
|
|
|
|
#define ice_debug_array(hw, type, rowsize, groupsize, buf, len) \
|
|
|
|
do { \
|
|
|
|
struct ice_hw *hw_l = hw; \
|
|
|
|
if ((type) & (hw_l)->debug_mask) { \
|
|
|
|
u16 len_l = len; \
|
|
|
|
u8 *buf_l = buf; \
|
|
|
|
int i; \
|
|
|
|
for (i = 0; i < (len_l - 16); i += 16) \
|
|
|
|
ice_debug(hw_l, type, "0x%04X %16ph\n",\
|
|
|
|
i, ((buf_l) + i)); \
|
|
|
|
if (i < len_l) \
|
|
|
|
ice_debug(hw_l, type, "0x%04X %*ph\n", \
|
|
|
|
i, ((len_l) - i), ((buf_l) + i));\
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
#endif /* DEBUG */
|
|
|
|
#endif /* CONFIG_DYNAMIC_DEBUG */
|
|
|
|
|
|
|
|
#endif /* _ICE_OSDEP_H_ */
|