Mitchell Wills | 5443a9f | 2016-08-18 11:44:58 -0700 | [diff] [blame] | 1 | /* |
| 2 | * Copyright 2016 The Android Open Source Project |
| 3 | * |
| 4 | * Licensed under the Apache License, Version 2.0 (the "License"); |
| 5 | * you may not use this file except in compliance with the License. |
| 6 | * You may obtain a copy of the License at |
| 7 | * |
| 8 | * http://www.apache.org/licenses/LICENSE-2.0 |
| 9 | * |
| 10 | * Unless required by applicable law or agreed to in writing, software |
| 11 | * distributed under the License is distributed on an "AS IS" BASIS, |
| 12 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 13 | * See the License for the specific language governing permissions and |
| 14 | * limitations under the License. |
| 15 | */ |
| 16 | |
| 17 | package android.hardware.wifi@1.0; |
| 18 | |
| 19 | import IWifiChipEventCallback; |
| 20 | |
| 21 | /** |
| 22 | * Interface that represents a chip that must be configured as a single unit. |
| 23 | * The HAL/driver/firmware will be responsible for determining which phy is used |
| 24 | * to perform operations like NAN, RTT, etc. |
| 25 | */ |
| 26 | interface IWifiChip { |
| 27 | enum InterfaceType : uint32_t { |
| 28 | STA, AP, P2P, |
| 29 | /** |
| 30 | * NAN control interface. Datapath support may be queried and created |
| 31 | * through this interface. |
| 32 | */ |
| 33 | NAN, |
| 34 | }; |
| 35 | |
| 36 | /** |
| 37 | * Set of interface types with the maximum number of interfaces that can have |
| 38 | * one of the specified type for a given ChipInterfaceCombination. See |
| 39 | * ChipInterfaceCombination for examples. |
| 40 | */ |
| 41 | struct ChipInterfaceCombinationLimit { |
| 42 | vec<InterfaceType> types; // Each InterfaceType may occur at most once |
| 43 | uint32_t maxIfaces; |
| 44 | }; |
| 45 | |
| 46 | /** |
| 47 | * Set of interfaces that can operate concurrently when in a given mode. See |
| 48 | * ChipMode below. |
| 49 | * |
| 50 | * For example: |
| 51 | * [{STA} <= 2] |
| 52 | * At most two STA interfaces are supported |
| 53 | * [], [STA], [STA+STA] |
| 54 | * |
| 55 | * [{STA} <= 1, {NAN} <= 1, {AP} <= 1] |
| 56 | * Any combination of STA, NAN, AP |
| 57 | * [], [STA], [NAN], [AP], [STA+NAN], [STA+AP], [NAN+AP], [STA+NAN+AP] |
| 58 | * |
| 59 | * [{STA} <= 1, {NAN,P2P} <= 1] |
| 60 | * Optionally a STA and either NAN or P2P |
| 61 | * [], [STA], [STA+NAN], [STA+P2P], [NAN], [P2P] |
| 62 | * Not included [NAN+P2P], [STA+NAN+P2P] |
| 63 | * |
| 64 | * [{STA} <= 1, {STA,NAN} <= 1] |
| 65 | * Optionally a STA and either a second STA or a NAN |
| 66 | * [], [STA], [STA+NAN], [STA+STA], [NAN] |
| 67 | * Not included [STA+STA+NAN] |
| 68 | */ |
| 69 | struct ChipInterfaceCombination { |
| 70 | vec<ChipInterfaceCombinationLimit> limits; |
| 71 | }; |
| 72 | |
| 73 | /** |
| 74 | * A mode that the chip can be put in. A mode defines a set of constraints on |
| 75 | * the interfaces that can exist while in that mode. Modes define a unit of |
| 76 | * configuration where all interfaces must be torn down to switch to a |
| 77 | * different mode. Some HALs may only have a single mode, but an example where |
| 78 | * multiple modes would be required is if a chip has different firmwares with |
| 79 | * different capabilities. |
| 80 | * |
| 81 | * When in a mode, it must be possible to perform any combination of creating |
| 82 | * and removing interfaces as long as at least one of the |
| 83 | * ChipInterfaceCombinations is satisfied. This means that if a chip has two |
| 84 | * available combinations, [{STA} <= 1] and [{AP} <= 1] then it is expected |
| 85 | * that exactly one STA interface or one AP interface can be created, but it |
| 86 | * is not expected that both a STA and AP interface could be created. If it |
| 87 | * was then there would be a single available combination |
| 88 | * [{STA} <=1, {AP} <= 1]. |
| 89 | * |
| 90 | * When switching between two available combinations it is expected that |
| 91 | * interfaces only supported by the initial combination will be removed until |
| 92 | * the target combination is also satisfied. At that point new interfaces |
| 93 | * satisfying only the target combination can be added (meaning the initial |
| 94 | * combination limits will no longer satisfied). The addition of these new |
| 95 | * interfaces should not impact the existence of interfaces that satisfy both |
| 96 | * combinations. |
| 97 | * |
| 98 | * For example, a chip with available combinations: |
| 99 | * [{STA} <= 2, {NAN} <=1] and [{STA} <=1, {NAN} <= 1, {AP} <= 1}] |
| 100 | * If the chip currently has 3 interfaces STA, STA and NAN and wants to add an |
| 101 | * AP interface in place of one of the STAs then first one of the STA |
| 102 | * interfaces must be removed and then the AP interface can be created after |
| 103 | * the STA had been torn down. During this process the remaining STA and NAN |
| 104 | * interfaces should not be removed/recreated. |
| 105 | * |
| 106 | * If a chip does not support this kind of reconfiguration in this mode then |
| 107 | * the combinations should be separated into two separate modes. Before |
| 108 | * switching modes all interfaces will be torn down, the mode switch will be |
| 109 | * enacted and when it completes the new interfaces will be brought up. |
| 110 | */ |
| 111 | struct ChipMode { |
| 112 | /** |
| 113 | * Id that can be used to put the chip in this mode. |
| 114 | */ |
| 115 | ChipModeId id; |
| 116 | |
| 117 | /** |
| 118 | * A list of the possible interface combinations that the chip can have |
| 119 | * while in this mode. |
| 120 | */ |
| 121 | vec<ChipInterfaceCombination> availableCombinations; |
| 122 | }; |
| 123 | |
| 124 | /** |
| 125 | * Requests notifications of significant events on this chip. Multiple calls |
| 126 | * to this will register multiple callbacks each of which will receive all |
| 127 | * events. |
| 128 | */ |
| 129 | oneway registerEventCallback(IWifiChipEventCallback callback); |
| 130 | |
| 131 | /** |
| 132 | * Get the set of operation modes that the chip supports. |
| 133 | */ |
| 134 | getAvailableModes() generates (vec<ChipMode> modes); |
| 135 | |
| 136 | /** |
| 137 | * Reconfigure the Chip. Will trigger onChipReconfigured. |
| 138 | * |
| 139 | * @param modeId The mode that the chip should switch to, corresponding to the |
| 140 | * id property of the target ChipMode. |
| 141 | */ |
| 142 | oneway configureChip(ChipModeId modeId); |
| 143 | |
| 144 | /** |
| 145 | * Get the current mode that the chip is in. |
| 146 | */ |
| 147 | getMode() generates (ChipModeId modeId); |
| 148 | |
| 149 | /** |
| 150 | * Request information about the chip. Will trigger onChipDebugInfoAvailable. |
| 151 | */ |
| 152 | oneway requestChipDebugInfo(); |
| 153 | |
| 154 | /** |
| 155 | * Request vendor debug info from the driver. Will trigger |
| 156 | * onDriverDebugDumpAvailable. |
| 157 | */ |
| 158 | oneway requestDriverDebugDump(); |
| 159 | |
| 160 | /** |
| 161 | * Request vendor debug info from the firmware. Will trigger |
| 162 | * onFirmwareDebugDumpAvailable. |
| 163 | */ |
| 164 | oneway requestFirmwareDebugDump(); |
| 165 | }; |