From: Mark Langsdorf <mark.langsdorf-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: "grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH 2/2 v2] sata highbank: add bit-banged SGPIO driver support
Date: Wed, 05 Jun 2013 15:19:30 -0500 [thread overview]
Message-ID: <51AF9D52.2030609@calxeda.com> (raw)
In-Reply-To: <20130604203251.GF14916-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
On 06/04/2013 03:32 PM, Tejun Heo wrote:
> Hello, Mark.
>
> On Tue, Jun 04, 2013 at 10:09:41AM -0500, Mark Langsdorf wrote:
>>> And tell ahci core sizeof(ecx_host_priv) some way, but really, just
>>> having a plain pointer should be enough, I think.
>>
>> I think I want to do the opposite. For 90% of the AHCI EM functions,
>> I want ecx_host_priv to be an ahci_host_priv so that I can use those
>> functions without having to keep a local copy of them.
>>
>> Would something like this:
>> struct ahci_host_priv {
>> /* standard AHCI existing stuff */
>> void *private_data;
>> };
>>
>> I shied away from that because a private data structure having a private
>> data structure doesn't seem right.
>
> Aren't we talking about the same thing? I'm perfectly fine with
> adding a pointer to ahci_host_priv. Maybe you can name it slightly
> differently - say, *impl_data, *platform_data, whatever.
I guess we are talking about the same thing. I'll do that.
>>>> +static ssize_t ecx_transmit_led_message(struct ata_port *ap, u32 state,
>>>> + ssize_t size)
>>>> +{
>>> ...
>>>> + if (!hpriv->em_msg_type & EM_MSG_TYPE_LED)
>>>> + return size;
>>>
>>> Is this really correct? You first negate and convert it to bool and
>>> then bit-wise and it with a mask? How is supposed to work?
>>
>> Am I confused about the order of operations? It's meant to be "continue
>> if hpriv->em_msg_type doesn't have EM_MSG_TYPE_LED set".
>
> Shouldn't that be
>
> if (!(hpriv->em_msg_type & EM_MSG_TYPE_LED))
>
> ! has higher priority than &. You're converting em_msg_type to 1 or 0
> and then and'ing EM_MSG_TYPE_LED to it.
I'll fix it then.
--Mark Langsdorf
Calxeda, Inc.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Langsdorf <mark.langsdorf@calxeda.com>
To: Tejun Heo <tj@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
Rob Herring <rob.herring@calxeda.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>
Subject: Re: [PATCH 2/2 v2] sata highbank: add bit-banged SGPIO driver support
Date: Wed, 05 Jun 2013 15:19:30 -0500 [thread overview]
Message-ID: <51AF9D52.2030609@calxeda.com> (raw)
In-Reply-To: <20130604203251.GF14916@htj.dyndns.org>
On 06/04/2013 03:32 PM, Tejun Heo wrote:
> Hello, Mark.
>
> On Tue, Jun 04, 2013 at 10:09:41AM -0500, Mark Langsdorf wrote:
>>> And tell ahci core sizeof(ecx_host_priv) some way, but really, just
>>> having a plain pointer should be enough, I think.
>>
>> I think I want to do the opposite. For 90% of the AHCI EM functions,
>> I want ecx_host_priv to be an ahci_host_priv so that I can use those
>> functions without having to keep a local copy of them.
>>
>> Would something like this:
>> struct ahci_host_priv {
>> /* standard AHCI existing stuff */
>> void *private_data;
>> };
>>
>> I shied away from that because a private data structure having a private
>> data structure doesn't seem right.
>
> Aren't we talking about the same thing? I'm perfectly fine with
> adding a pointer to ahci_host_priv. Maybe you can name it slightly
> differently - say, *impl_data, *platform_data, whatever.
I guess we are talking about the same thing. I'll do that.
>>>> +static ssize_t ecx_transmit_led_message(struct ata_port *ap, u32 state,
>>>> + ssize_t size)
>>>> +{
>>> ...
>>>> + if (!hpriv->em_msg_type & EM_MSG_TYPE_LED)
>>>> + return size;
>>>
>>> Is this really correct? You first negate and convert it to bool and
>>> then bit-wise and it with a mask? How is supposed to work?
>>
>> Am I confused about the order of operations? It's meant to be "continue
>> if hpriv->em_msg_type doesn't have EM_MSG_TYPE_LED set".
>
> Shouldn't that be
>
> if (!(hpriv->em_msg_type & EM_MSG_TYPE_LED))
>
> ! has higher priority than &. You're converting em_msg_type to 1 or 0
> and then and'ing EM_MSG_TYPE_LED to it.
I'll fix it then.
--Mark Langsdorf
Calxeda, Inc.
next prev parent reply other threads:[~2013-06-05 20:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-30 20:17 [PATCH 1/2] ahci: make ahci_transmit_led_message into a function pointer Mark Langsdorf
2013-05-30 20:17 ` [PATCH 2/2] sata highbank: add bit-banged SGPIO driver support Mark Langsdorf
2013-05-31 1:17 ` Tejun Heo
[not found] ` <1369945051-2582-2-git-send-email-mark.langsdorf-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
2013-06-03 13:35 ` [PATCH 2/2 v2] " Mark Langsdorf
2013-06-03 13:35 ` Mark Langsdorf
2013-06-03 20:37 ` Tejun Heo
2013-06-04 15:09 ` Mark Langsdorf
2013-06-04 20:32 ` Tejun Heo
[not found] ` <20130604203251.GF14916-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-06-05 20:19 ` Mark Langsdorf [this message]
2013-06-05 20:19 ` Mark Langsdorf
2013-06-05 22:31 ` [PATCH 2/2] " Mark Langsdorf
2013-06-05 23:15 ` Tejun Heo
[not found] ` <20130605231517.GP10693-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2013-06-06 12:14 ` Mark Langsdorf
2013-06-06 12:14 ` Mark Langsdorf
2013-06-06 12:52 ` [PATCH 2/2 v4] " Mark Langsdorf
2013-06-06 21:06 ` Tejun Heo
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=51AF9D52.2030609@calxeda.com \
--to=mark.langsdorf-bsgfqqb8/dxbdgjk7y7tuq@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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: link
Be 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.