On Tue, Apr 28, 2020 at 12:05:35PM +0300, Jani Nikula wrote:
> On Tue, 28 Apr 2020, Imre Deak wrote:
> > On Tue, Apr 28, 2020 at 10:55:49AM +0300, Jani Nikula wrote:
> >> On Thu, 23 Apr 2020, Imre Deak wrote:
> >> > Using an AUX channel which by default belongs to a non-TypeC PHY won't
> >> > wor
On Tue, 28 Apr 2020, Imre Deak wrote:
> On Tue, Apr 28, 2020 at 10:55:49AM +0300, Jani Nikula wrote:
>> On Thu, 23 Apr 2020, Imre Deak wrote:
>> > Using an AUX channel which by default belongs to a non-TypeC PHY won't
>> > work on a TypeC PHY, since - as a side-effect besides providing an AUX
>>
On Tue, Apr 28, 2020 at 10:55:49AM +0300, Jani Nikula wrote:
> On Thu, 23 Apr 2020, Imre Deak wrote:
> > Using an AUX channel which by default belongs to a non-TypeC PHY won't
> > work on a TypeC PHY, since - as a side-effect besides providing an AUX
> > channel - the AUX channel power well affect
On Thu, 23 Apr 2020, Imre Deak wrote:
> Using an AUX channel which by default belongs to a non-TypeC PHY won't
> work on a TypeC PHY, since - as a side-effect besides providing an AUX
> channel - the AUX channel power well affects power manangement specific
> to the TypeC subsystem. Using a TypeC
Using an AUX channel which by default belongs to a non-TypeC PHY won't
work on a TypeC PHY, since - as a side-effect besides providing an AUX
channel - the AUX channel power well affects power manangement specific
to the TypeC subsystem. Using a TypeC AUX channel on a non-TypeC PHY
would probably a
