From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> To: Mark Rutland <mark.rutland@arm.com> Cc: ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org, nbd@nbd.name, chunkeey@googlemail.com, robh+dt@kernel.org Subject: Re: [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding Date: Mon, 27 Jun 2016 16:58:53 +0200 [thread overview] Message-ID: <CAFBinCBJdibUJH1jwEZObWVLNAGyh+ZH9XzB1CbmoGr+nUZYbg@mail.gmail.com> (raw) In-Reply-To: <20160627125709.GF1113@leverpostej> On Mon, Jun 27, 2016 at 2:57 PM, Mark Rutland <mark.rutland@arm.com> wrote: >> > Please find a better way to identify relevant FW. What exactly affects >> > which FW can be used, or would ideally be used? Are different FWs >> > required for the same HW in some contexts? >> > >> > Can we not figure out the relevant FW names in the driver based on some >> > identification mechanism (e.g. a more thoroughly defined set of >> > compatible strings)? >> The only way of auto-detecting a "correct" name would be via >> dev_name() (with some prefix this could give something like >> ath9k-pci-0000:00:0e.0.bin). > > That may work, if the above is not an option. I would also prefer this (Felix' email already contains an explanation why this way is preferred and I fully agree with him). >> >> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and >> >> + swapping of the EEPROM data if required >> > >> > CAn we not simply always do this? >> I've asked myself this question as well, but unfortunately some >> manufacturers ship the EEPROM data with incorrect endianness magic. >> Thus I decided to stay consistent with ath9k_platform_data which also >> has a boolean (which defaults to false). > > Ah. It's probably worth a note in the binding that this is not always > safe, and should only be set if the eeprom is known to have valid > endianness magic. > > It would also be worth specifying teh behaviour in the absence of this > property. noted, I will fix this in the next round >> >> >> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM >> >> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM >> > >> > When/why would these be necessary? >> sometimes a manufacturer (accidentally) leaves both bands enabled in >> the EEPROM data,while the RF hardware is only suitable for one of both >> bands. The same settings exist in ath9k_platform_data, serving exactly >> the same purpose > > Ok. Can we invert these instead (i.e. describe when the feature is > available)? e.g. qca,supports-2ghz. we could invert these, but I think the "disable" logic was chosen with a good reason: the ath9k calibration data already contains the information which bands are enabled/disabled. Enabling a band via devicetree / platform data is not possible, because that would mean we would have to pass additional calibration data for this band. The only use-case where these disable-Xghz properties are used is when the device vendor forgot to disable one of the bands. I can improve the documentation for this one, but I would prefer to stay with the disable naming/logic Martin
WARNING: multiple messages have this Message-ID (diff)
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> To: ath9k-devel@lists.ath9k.org Subject: [ath9k-devel] [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding Date: Mon, 27 Jun 2016 16:58:53 +0200 [thread overview] Message-ID: <CAFBinCBJdibUJH1jwEZObWVLNAGyh+ZH9XzB1CbmoGr+nUZYbg@mail.gmail.com> (raw) In-Reply-To: <20160627125709.GF1113@leverpostej> On Mon, Jun 27, 2016 at 2:57 PM, Mark Rutland <mark.rutland@arm.com> wrote: >> > Please find a better way to identify relevant FW. What exactly affects >> > which FW can be used, or would ideally be used? Are different FWs >> > required for the same HW in some contexts? >> > >> > Can we not figure out the relevant FW names in the driver based on some >> > identification mechanism (e.g. a more thoroughly defined set of >> > compatible strings)? >> The only way of auto-detecting a "correct" name would be via >> dev_name() (with some prefix this could give something like >> ath9k-pci-0000:00:0e.0.bin). > > That may work, if the above is not an option. I would also prefer this (Felix' email already contains an explanation why this way is preferred and I fully agree with him). >> >> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and >> >> + swapping of the EEPROM data if required >> > >> > CAn we not simply always do this? >> I've asked myself this question as well, but unfortunately some >> manufacturers ship the EEPROM data with incorrect endianness magic. >> Thus I decided to stay consistent with ath9k_platform_data which also >> has a boolean (which defaults to false). > > Ah. It's probably worth a note in the binding that this is not always > safe, and should only be set if the eeprom is known to have valid > endianness magic. > > It would also be worth specifying teh behaviour in the absence of this > property. noted, I will fix this in the next round >> >> >> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM >> >> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM >> > >> > When/why would these be necessary? >> sometimes a manufacturer (accidentally) leaves both bands enabled in >> the EEPROM data,while the RF hardware is only suitable for one of both >> bands. The same settings exist in ath9k_platform_data, serving exactly >> the same purpose > > Ok. Can we invert these instead (i.e. describe when the feature is > available)? e.g. qca,supports-2ghz. we could invert these, but I think the "disable" logic was chosen with a good reason: the ath9k calibration data already contains the information which bands are enabled/disabled. Enabling a band via devicetree / platform data is not possible, because that would mean we would have to pass additional calibration data for this band. The only use-case where these disable-Xghz properties are used is when the device vendor forgot to disable one of the bands. I can improve the documentation for this one, but I would prefer to stay with the disable naming/logic Martin
next prev parent reply other threads:[~2016-06-27 14:59 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-23 17:45 [RFC v2] ath9k: add devicetree support to ath9k Martin Blumenstingl 2016-06-23 17:45 ` [ath9k-devel] " Martin Blumenstingl 2016-06-23 17:45 ` [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding Martin Blumenstingl 2016-06-23 17:45 ` [ath9k-devel] " Martin Blumenstingl 2016-06-23 17:58 ` Mark Rutland 2016-06-23 18:08 ` [ath9k-devel] " Mark Rutland 2016-06-23 18:14 ` Martin Blumenstingl 2016-06-23 18:14 ` [ath9k-devel] " Martin Blumenstingl 2016-06-27 12:57 ` Mark Rutland 2016-06-27 12:57 ` [ath9k-devel] " Mark Rutland 2016-06-27 13:07 ` Felix Fietkau 2016-06-27 13:07 ` [ath9k-devel] " Felix Fietkau 2016-06-27 14:58 ` Martin Blumenstingl [this message] 2016-06-27 14:58 ` Martin Blumenstingl 2016-06-23 19:25 ` Arend Van Spriel 2016-06-23 19:33 ` [ath9k-devel] " Arend Van Spriel 2016-06-23 21:46 ` Martin Blumenstingl 2016-06-23 21:46 ` [ath9k-devel] " Martin Blumenstingl 2016-06-23 17:45 ` [PATCH RFC v2 2/2] ath9k: parse the device configuration from an OF node Martin Blumenstingl 2016-06-23 17:45 ` [ath9k-devel] " Martin Blumenstingl
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAFBinCBJdibUJH1jwEZObWVLNAGyh+ZH9XzB1CbmoGr+nUZYbg@mail.gmail.com \ --to=martin.blumenstingl@googlemail.com \ --cc=ath9k-devel@lists.ath9k.org \ --cc=ath9k-devel@qca.qualcomm.com \ --cc=chunkeey@googlemail.com \ --cc=linux-wireless@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=nbd@nbd.name \ --cc=robh+dt@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.