Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make init scripts executable. #3

Merged
merged 1 commit into from
Jan 24, 2017
Merged

Conversation

oleksandrivantsiv
Copy link
Contributor

No description provided.

@dvirl1 dvirl1 merged commit 2a26af7 into Mellanox:master Jan 24, 2017
MellanoxBSP pushed a commit that referenced this pull request Aug 17, 2020
…ionality and update licenses

The patchset adds new features for the existing Mellanox systems.

Patches #1-#2 update license to SPDX-License.
Patch #3  moves header file out of x86 realm.
Patch #4 adds support for word address space devices.
Patch #5 extends mux number supported by driver.

i2c: mux: mlxcpld: Update module license

Update license to SPDX-License.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

platform/x86: mlxcpld: Update module license

Update license to SPDX-License.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

i2c: mux: mlxcpld: Move header file out of x86 realm

Move out header file from include/linux/platform_data/x86/ to
include/linux/platform_data/, since it does not depend on x86
architecture.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

i2c: mux: mlxcpld: Extend driver to support word address space devices

Extend driver to allow I2C routing control through CPLD devices with
word address space. Till now only CPLD devices with byte address space
have been supported.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Michael Shych <michaelsh@mellanox.com>

i2c: mux: mlxcpld: Allow to extend mux number

Allow to extend mux number supported by driver.
Currently it is limited by eight, which is not enough for new coming
Mellanox modular system with line cards, which require up to 64 mux
support.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Michael Shych <michaelsh@mellanox.com>
MellanoxBSP pushed a commit that referenced this pull request Aug 17, 2020
…ionality and update licenses

The patchset adds new features for the existing Mellanox systems.

Patches #1-#2 update license to SPDX-License.
Patch #3  moves header file out of x86 realm.
Patch #4 adds support for word address space devices.
Patch #5 extends mux number supported by driver.

i2c: mux: mlxcpld: Update module license

Update license to SPDX-License.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

platform/x86: mlxcpld: Update module license

Update license to SPDX-License.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

i2c: mux: mlxcpld: Move header file out of x86 realm

Move out header file from include/linux/platform_data/x86/ to
include/linux/platform_data/, since it does not depend on x86
architecture.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

i2c: mux: mlxcpld: Extend driver to support word address space devices

Extend driver to allow I2C routing control through CPLD devices with
word address space. Till now only CPLD devices with byte address space
have been supported.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Michael Shych <michaelsh@mellanox.com>

i2c: mux: mlxcpld: Allow to extend mux number

Allow to extend mux number supported by driver.
Currently it is limited by eight, which is not enough for new coming
Mellanox modular system with line cards, which require up to 64 mux
support.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Michael Shych <michaelsh@mellanox.com>
sholeksandr pushed a commit that referenced this pull request Nov 12, 2020
…ionality and update licenses

The patchset adds new features for the existing Mellanox systems.

Patches #1-#2 update license to SPDX-License.
Patch #3  moves header file out of x86 realm.
Patch #4 adds support for word address space devices.
Patch #5 extends mux number supported by driver.

i2c: mux: mlxcpld: Update module license

Update license to SPDX-License.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

platform/x86: mlxcpld: Update module license

Update license to SPDX-License.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

i2c: mux: mlxcpld: Move header file out of x86 realm

Move out header file from include/linux/platform_data/x86/ to
include/linux/platform_data/, since it does not depend on x86
architecture.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

i2c: mux: mlxcpld: Extend driver to support word address space devices

Extend driver to allow I2C routing control through CPLD devices with
word address space. Till now only CPLD devices with byte address space
have been supported.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Michael Shych <michaelsh@mellanox.com>

i2c: mux: mlxcpld: Allow to extend mux number

Allow to extend mux number supported by driver.
Currently it is limited by eight, which is not enough for new coming
Mellanox modular system with line cards, which require up to 64 mux
support.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Michael Shych <michaelsh@mellanox.com>
sholeksandr pushed a commit that referenced this pull request Nov 12, 2020
…ionality and update licenses

The patchset adds new features for the existing Mellanox systems.

Patches #1-#2 update license to SPDX-License.
Patch #3  moves header file out of x86 realm.
Patch #4 adds support for word address space devices.
Patch #5 extends mux number supported by driver.

i2c: mux: mlxcpld: Update module license

Update license to SPDX-License.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

platform/x86: mlxcpld: Update module license

Update license to SPDX-License.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

i2c: mux: mlxcpld: Move header file out of x86 realm

Move out header file from include/linux/platform_data/x86/ to
include/linux/platform_data/, since it does not depend on x86
architecture.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>

i2c: mux: mlxcpld: Extend driver to support word address space devices

Extend driver to allow I2C routing control through CPLD devices with
word address space. Till now only CPLD devices with byte address space
have been supported.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Michael Shych <michaelsh@mellanox.com>

i2c: mux: mlxcpld: Allow to extend mux number

Allow to extend mux number supported by driver.
Currently it is limited by eight, which is not enough for new coming
Mellanox modular system with line cards, which require up to 64 mux
support.

Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Michael Shych <michaelsh@mellanox.com>
vadimp-nvidia added a commit that referenced this pull request Dec 2, 2020
… Ethernet system

Add initial chassis management support for Nvidia modular Ethernet
switch systems MSN4800, providing a high performance switching solution
for Enterprise Data Centers (EDC) for building Ethernet based clusters,
High-Performance Computing (HPC) and embedded environments.

This system could be equipped with the different types of replaceable
line cards and management board. The first system flavor will support
the line card type MSN4800-C16 equipped with Lattice CPLD devices aimed
for system and ASIC control, one Nvidia FPGA for gearboxes (PHYs)
management, and four Nvidia gearboxes for the port control and with
16x100GbE QSFP28 ports and also with various devices for electrical
control.

The system is equipped with eight slots for line cards, four slots for
power supplies and six slots for fans. It could be configured as fully
populated or with even only one line card. The line cards are
hot-pluggable.
In the future when more line card flavors are to be available (for
example line cards with 8x200Gb Eth port, with 4x400 Eth ports, or with
some kind of smart cards for offloading purpose), any type of line card
could be inserted at any slot.

The system is based on Nvidia Spectrum-3 ASIC. The switch height is
4U and it fits standard rack size.

Whenever a line card is enabled (inserted, verified, powered on,
configured by firmware), all the ports, thermal control, hardware
monitoring and cables related objects should be dynamically created.
Whenever a line card is disabled (put in reset state, powered off,
removed) all these objects should be removed.

The patchset provides initial support for system management. It extends
functionality of thermal control, hardware monitoring, cable QSFP
access, while all these objects are located within the line card.

mlxsw: reg: Extend MTMP register with new slot number field

Extend MTMP (Management Temperature Register) with new field specifying
the slot number. The purpose of this field is to support access to MTMP
register for reading temperature sensors on modular system.
For '1U' systems the 'sensor_index' uniquely identifies the cage
sensors, while 'slot_index' is always 0. For modular systems the
sensors are identified by:
- 'slot_index', specifying the slot number, where line card is located;
- 'sensor_index', specifying cage sensor within the line card.

mlxsw: reg: Extend MTBR register with new slot number field

Extend MTBR (Management Temperature Bulk Register) with new field
specifying the slot number. The purpose of this field is to support
access to MTBR register for reading temperature sensors on modular
system. For '1U' systems the 'sensor_index' uniquely identifies the
cage sensors. For modular systems the sensors are identified by two
indexes:
- 'slot_index', specifying the slot number, where line card is located;
- 'sensor_index', specifying cage sensor within the line card.

mlxsw: reg: Extend MCIA register with new slot number field

Extend MCIA (Management Cable Info Access Register) with new field
specifying the slot number. The purpose of this field is to support
access to MCIA register for reading cage cable information on modular
system. For '1U' systems the 'module' number uniquely identifies the
transceiver location. For modular systems the transceivers are
identified by two indexes:
- 'slot_index', specifying the slot number, where line card is located;
- 'module', specifying cage transceiver within the line card.

mlxsw: reg: Extend MGPIR register with new slot number field

Extend MGPIR (Management General Peripheral Information Register) with
new field specifying the slot number. The purpose of this field is to
support access to MPGIR register on modular system for getting the
number of cage, equipped on the line card, inserted at specified slot.
In case slot number is set zero, MGPIR will provide the information for
the main board. For Top of the Rack (non-modular) system it will
provide the same as before.

mlxsw: core_hwmon: Fix variable names for hwmon attributes

Replace all local variables 'mlwsw_hwmon_attr' by 'mlxsw_hwmon_attr'.
All variable prefixes should start with 'mlxsw' according to the naming
convention, so 'mlwsw' is changed to 'mlxsw'.

mlxsw: core_hwmon: Split gearbox initialization

Split gearbox initialization in two routines - the first one is to be
used for gearbox configuration validation, the second for creation of
gearbox related 'hwmon' attributes if any.

Currently, mlxsw supports gearbox hwmon attributes corresponding to the
objects discovered on the main board. Same hwmon attributes could be
also discovered on line cards. While the initialization flow for main
board and for line cards is the same, the configuration flow is
different.

The purpose of this patch is to allow reusing of initialization flow by
main board and line cards.

mlxsw: core_hwmon: Extend internal structures to support multi hwmon objects

Currently, mlxsw supports a single hwmon device and registers it with
attributes corresponding to the various objects found on the main
board such as fans and gearboxes.

Line cards can have the same objects, but unlike the main board they
can be added and removed while the system is running. The various
hwmon objects found on these line cards should be created when the
line card becomes available and destroyed when the line card becomes
unavailable.

The above can be achieved by representing each line card as a
different hwmon device and registering / unregistering it when the
line card becomes available / unavailable.

Prepare for multi hwmon device support by splitting
'struct mlxsw_hwmon' into 'struct mlxsw_hwmon' and
'struct mlxsw_hwmon_dev'. The first will hold information relevant to
all hwmon devices, whereas the second will hold per-hwmon device
information.

mlxsw: core_hwmon: Introduce slot parameter in hwmon interfaces

Add 'slot' parameter to 'mlxsw_hwmon_dev' structure. Use this parameter
in mlxsw_reg_mtmp_pack(), mlxsw_reg_mtbr_pack() and
Use mlxsw_reg_mtmp_slot_index_set() routines.
For main board it'll always be zero, for line cards it'll be set to
the physical slot number in modular systems.

mlxsw: core_hwmon: Extend hwmon device with gearbox mapping field

Add gearbox mapping field to 'mlxsw_hwmon_dev' structure. It should
provide the mapping for gearbox sensor indexes, given gearbox number.
For main board mapping is supposed to be always sequential, while for
line cards on modular system it could be non-sequential.

mlxsw: core_thermal: Extend internal structures to support multi thermal areas

Introduce intermediate level for thermal zones areas.
Currently all thermal zones are associated with thermal objects located
within the main board. Such objects are created during driver
initialization and removed during driver de-initialization.

For line cards in modular system the thermal zones are to be associated
with the specific line card. They should be created whenever new line
card is available (inserted, validated, powered and enabled) and
removed, when line card is getting unavailable.
The thermal objects found on the line card #n are accessed by setting
slot index to #n, while for access to objects found on the main board
slot index should be set to default value zero.

Each thermal area contains the set of thermal zones associated with
particular slot index.
Thus introduction of thermal zone areas allows to use the same APIs for
the main board and line cards, by adding slot index argument.

mlxsw: core_thermal: Introduce slot argument in thermal interfaces

Add 'slot_index' argument to 'mlxsw_thermal_module' and
'mlxsw_thermal_area' structures. Use it in mlxsw_reg_mtmp_pack() for
setting slot number for the thermal zones associated with the cages and
gearboxes.

For main board it'll be always zero, for line cards it'll be set to
the physical slot number in modular systems.

The thermal zones associated with ASIC ambient temperatures should be
always accessed with slot zero - main thermal zone.

mlxsw: core: Extend interfaces for cable info access with slot argument

Extend APIs mlxsw_env_get_module_eeprom(), mlxsw_env_get_module_info()
used for reading cable information with slot index argument.
Extend API mlxsw_env_init() used for environment initialization with
slot index argument.
For main board slot will be always set to zero and these APIs will work
as before. If reading cable information is required from the cages
located on line card, slot should be set to the physical slot number, where
line card is located in modular systems.

mlxsw: minimal: Extend port structure with slot index field

A number of registers have been extended with 'slot_index' field for
line card support. The purpose of this field is to indicate the
location of the port, so that it could be used when trying to read
module info.

For main board it'll always be zero, for line cards it'll be set to the
physical slot number at which line card is located. For now the slot
index is always 0.
That is, ports are still not instantiated from line cards.

Add 'slot_index' field to 'mlxsw_m_port' structure. Use it for module
info access.

mlxsw: core_thermal: Rename labels according to naming convention

Rename labels for error flow handling in order to align with naming
convention used in rest 'mlxsw' code.

mlxsw: core_thermal: Split gearbox initialization

Split gearbox initialization in two routines - the first one is to be
used for gearbox configuration validation, the second for creation of
gearbox related thermal zones if any.

Currently, mlxsw supports gearbox thermal zones corresponding to the
main board. For system equipped with the line cards assembled with the
gearboxes, thermal zones will be associated with the gearboxes found on
those line cards.

While the initialization flow for main board and for line cards is the
same, the configuration flow is different.

The purpose of this patch is to allow reusing of initialization flow by
main board and line cards.

mlxsw: core_thermal: Extend thermal area with gearbox mapping field

Add gearbox mapping field 'gearbox_sensor_map' to
'mlxsw_thermal_module' structure. It should provide the mapping for
gearbox sensor indexes, given gearbox number. For main board mapping is
supposed to be always sequential, while for line cards on modular
system it could be non-sequential.

mlxsw: core_thermal: Add line card id prefix to line card thermal zone name

Add prefix "lc#n" to thermal zones associated with the thermal objects
found on line cards.

For example thermal zone for module #9 located at line card #7 will
have type:
mlxsw-lc7-module9.
And thermal zone for gearbox #3 located at line card #5 will have type:
mlxsw-lc5-gearbox3.

mlxsw: core_hwmon: Add line card id prefix to line card label attribute names

Add prefix "linecard#n" to 'hwmon' label attributes for the 'hwmon'
objects found on the line cards.

For example cage temperature for module #9 located at line card #7 will
be exposed by utility 'sensors' like:
linecard#07 front panel 009:	+32.0°C  (crit = +70.0°C, emerg = +80.0°C)
And temperature for gearbox #3 located at line card #5 will be exposed
like:
linecard#05 gearbox 003:		+41.0°C  (highest = +41.0°C)

For now the slot index is always 0 and field 'name' of the structure
'mlxsw_hwmon_dev' is empty. For line card this field is supposed to
be initialized to 'linecard#n', when line card in slot #n is enabled.

Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
vadimp-nvidia added a commit that referenced this pull request Feb 28, 2021
… and thermal

Add line card thermal area registration and de-registration interfaces
to thermal initialization/de-initialization flows.

Add callback for line card thermal area activation and de-activation.
These callbacks are to be invoked, when firmware indicates it got
active or inactive state.

When "active event" is received for particular line card, its thermal
interfaces should be configured according to the configuration obtained
from the firmware. When opposite "inactive event" is received all these
interfaces should be removed.

Each line card is associated with the relevant thermal area, which may
contain thermal zones for cages and gearboxes found on this line card.

For example thermal zone for module #9 located at line card #7 will
have type:
mlxsw-lc7-module9.
And thermal zone for gearbox #2 located at line card #5 will have type:
mlxsw-lc5-gearbox2.

Add line card 'hwmon' registration and de-registration interfaces to
'hwmon' initialization/de-initialization flows.

Add callback for line card 'hwmon' objects activation and
de-activation. These callbacks are to be invoked, when firmware
indicates it got active or inactive state.

When "active event" is received for particular line card, its 'hwmon'
interfaces should be configured according to the configuration obtained
from the firmware. When opposite "inactive event" is received all these
interfaces should be removed.

Each line card is associated with the relevant 'hwmon' devices, which
may contain thermal attributes for the cages and gearboxes found on
this line card.

For example cage temperature for module #9 located at line card #7 will
be exposed by utility 'sensors' like:
linecard#07 front panel 009:	+32.0°C  (crit = +70.0°C, emerg = +80.0°C)
And temperature for gearbox #3 located at line card #5 will be exposed
like:
linecard#05 gearbox 003:		+41.0°C  (highest = +41.0°C)

Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
vadimp-nvidia added a commit that referenced this pull request Feb 28, 2021
… and thermal

Add line card thermal area registration and de-registration interfaces
to thermal initialization/de-initialization flows.

Add callback for line card thermal area activation and de-activation.
These callbacks are to be invoked, when firmware indicates it got
active or inactive state.

When "active event" is received for particular line card, its thermal
interfaces should be configured according to the configuration obtained
from the firmware. When opposite "inactive event" is received all these
interfaces should be removed.

Each line card is associated with the relevant thermal area, which may
contain thermal zones for cages and gearboxes found on this line card.

For example thermal zone for module #9 located at line card #7 will
have type:
mlxsw-lc7-module9.
And thermal zone for gearbox #2 located at line card #5 will have type:
mlxsw-lc5-gearbox2.

Add line card 'hwmon' registration and de-registration interfaces to
'hwmon' initialization/de-initialization flows.

Add callback for line card 'hwmon' objects activation and
de-activation. These callbacks are to be invoked, when firmware
indicates it got active or inactive state.

When "active event" is received for particular line card, its 'hwmon'
interfaces should be configured according to the configuration obtained
from the firmware. When opposite "inactive event" is received all these
interfaces should be removed.

Each line card is associated with the relevant 'hwmon' devices, which
may contain thermal attributes for the cages and gearboxes found on
this line card.

For example cage temperature for module #9 located at line card #7 will
be exposed by utility 'sensors' like:
linecard#07 front panel 009:	+32.0°C  (crit = +70.0°C, emerg = +80.0°C)
And temperature for gearbox #3 located at line card #5 will be exposed
like:
linecard#05 gearbox 003:		+41.0°C  (highest = +41.0°C)

Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants