[PATCH 2/7] wcn36xx: get chip type from platform ops
Eugene Krasnikov
k.eugene.e at gmail.com
Wed Jun 10 12:20:38 PDT 2015
Sounds good to me as well.
2015-06-10 1:39 GMT+01:00 Andy Green <andy.green at linaro.org>:
>
> On Wed, 10 Jun 2015 06:34 Bjorn Andersson <bjorn at kryo.se> wrote:
>
> On Mon, Jun 8, 2015 at 12:01 AM, yfw <fengwei.yin at linaro.org> wrote:
>> Hi Eugene,
>>
>> On 2015/6/1 16:06, Eugene Krasnikov wrote:
>>>
>>> Do you think it will be difficult to get get_chip_type on all platforms?
>>>
>> There is no input from this mail list. I suppose it's OK to change it? And
>> what do you think about other changes? Are they ready for merging? Thanks.
>>
>
> Sorry for not responding sooner.
>
> Based on my suggested smd patches (that I'm about to resend), the
> wcn36xx driver would become a smd client driver, probed by the
> WLAN_CTRL channel coming up. The driver would be identified based on a
> compatible string (like most other drivers).
>
> With all prerequisites in mainline, and the lack of board files, I
> think we should simply drop the "platform glue" part from wcn36xx and
> simply interface with the new smd code directly.
>
> wcn36xx is one of the drivers that I've used to test my smd code with,
> so I have these patches "ready". I've gotten some minor comments on
> the current patchset, so I will resend it shortly and as that settles
> I intend to send my wcn36xx patches for adapting to the new interface.
>
> So, I think we should simply get the wcn version from a compatible
> sting such as "qcom,wcn3680".
>
> Sounds good to me... the platform business is only there in the first place
> to provide cover for the transport pieces being OOT. If that's no longer
> the case then the wcn platform crutch lost its reason for existing and it
> should just become a normal DT platform, since all the qcom kernels are
> DT-only anyway.
>
> -Andy
>
> Regards,
> Bjorn
>
>
--
Best regards,
Eugene
More information about the wcn36xx
mailing list